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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The present document describes the Content Delivery Network (CDN) functional architecture, the interconnection with 
IMS-based and NGN Integrated IPTV solutions and user-related procedures in relationship with the unicast stored 
(e.g. content download) and streaming (e.g. CoD) services as defined in TS 181 016 [1]. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and 
IPTV". 

[2] ETSI TS 182 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 
subsystem". 

[3] ETSI TS 182 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN integrated IPTV subsystem Architecture". 

[4] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 102 990: "Media Content Distribution (MCD); CDN Interconnection, use cases and 

requirements". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

consumer: entity where the content is consumed 

content acquisition: act of acquiring content from a content source 

content delivery: act of delivering deployed content to a user 



£75/ 



8 ETSI TS 1 82 01 9 V3.1 .2 (201 1 -09) 

Content Delivery Network (CDN): set of functions managing content acquired from content sources, through delivery 
to the user 

content deployment: act of repHcating and/or moving ingested content to one or more network entities, based on 
content deployment policies 

content distribution: act of moving content within or between networks 

content ingestion: act of preparing and introducing acquired content (and associated data) for the first time to an initial 
server location 

content publishing: act of making the content available for access 

content provider: entity that owns or is licensed to sell content or content assets 

pull: within the CDN, a content delivery method in which the requesting entity initiates the media flow by requesting 
content from the providing entity 

push: within the CDN, a content delivery method in which the providing entity initiates the media flow to the 
requesting destination entity 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ALF Asset Location Function 

CCF Cluster Controller Function 

C-COF Control plane COF 

CDF Content Delivery Function 

CDN Content Delivery Network 

CDNCF Content Delivery Network Control Function 

CoD Content on Demand 

COF Content Origin Function 

D-COF Data plane COF 

FE Functional Element 

EEC Forward Error Correction 

IMS IP Multimedia Subsystem 

IPTV Internet Protocol Television 

LRU Least Recently Used 

MCE Media Control Function 

MDF Media Delivery Function 

ME Media Function 

NASS Network Attachment Sub-System 

NAT Network Address Translation 

NGN Next Generation Network 

QoS Quality of Service 

RTP Real Time Protocol 

SCE Service Control Function 

SSF Service Selection Function 

TV Television 

UDP User Datagram Protocol 

UE User Equipment 

UGC User Generated Content 



General description of CDN 



A Content Delivery Network (CDN) is a collaborative collection of components, where content is replicated over 
several mirrored servers in order to perform transparent and effective delivery of content to end users. 
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The major stages of CDN are: 

• Content acquisition: Acquiring content from a content source, including: 

Pre-Positioning: content acquisition triggered prior to actual corresponding content request by users. 
Dynamic Acquisition: content acquisition triggered at the time it is requested by users. 

• Content ingestion: Preparing and introducing acquired content (and associated data) for the first time to an 
initial server location. 

• Content deployment: Replicating and/or moving ingested content to one or more network entities, based on 
content deployment policies. 

The CDN model for distributing content is based on rephcated servers located at the edge of the network (to which end 
users are connected) for delivering content to end users in a reliable and timely manner. The content can be replicated in 
advance or on-demand. 

The CDN goals are: 

• Scalability: the ability to expand, in order to handle new amount of data and requests. 

• Performance: response time, or latency, that end users perceive. 

• Reliability: makes the service always available. 

• Security: prevent unauthorized access and modification of the content. 

The CDN functional architecture defined in the present document is independent of the service system. The CDN is 
transparent to media formats, content protection (whether the content is encrypted or not, or which content protection 
solution is implemented) and the service types. While the CDN is specified herein in the context of IPTV, it may be 
utilized where appropriate for other services. 

NOTE: CDN Interconnection between different service provider domains is addressed in annex D and 
TS102 990[i.l]. 



4.1 Functional roles and CDN relationships 

The present document describes the TISPAN CDN architecture, the interconnection of CDNs in the user-facing service 
delivery network, including the interfacing with IPTV subsystems defined in TS 182 027 [2] and TS 182 028 [3], and 
CDN content ingestion. 

For the purpose of the present document, concepts of domains, and roles are defined in this clause and are illustrated in 
figure 4.1.1. The terminology in this clause is based on TS 181 016 [1], clause 4.1. 
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Figure 4.1.1: Roles and domain relationships for CDN 
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The CDN service provider is the entity that ingests, deploys and dehvers content. 

NOTE 1: The CDN service provider may have muhiple interconnected CDNs. 

The IPTV service provider is the entity that offers IPTV services to the consumers making use of the dehvering CDN 
for content delivery. 

NOTE 2: The present document assumes that the roles of CDN service provider and IPTV service provider take 
place within TISPAN-specified service domain(s). The case where these two roles are in different 
domains is described in TS 182 027 [2], clause 6.9. 

The Consumer is the entity where the content is consumed. The content is deUvered through the CDN domain. 

The Content Provider is the entity that owns or is licensed to sell content or content assets. The content is delivered to 
a user through the CDN. The content Provider is authoritative with respect to control of consumer access to the content 
(i.e. whether a given delivery request from a consumer is to be honoured by the CDN or not). 



4.2 High level functional overview 

The following picture shows the main components of a CDN. 



Content Acquisition 



Content Preparation 



Request Routing 
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Replica server 1 



Replica server IVI 



Content Delivery 



Figure 4.2.1 : Architectural components of a CDN 

The content deployment component is in charge of generating copies of content inside the CDN and controls the 
procedure of content deployment. When content is ingested from a content source (i.e. content provider, or UE for UGC 
service) the content deployment component should record the metadata and location(s) of the content. More than one 
copy of the content may be deployed to different replica servers during the procedure for content ingestion or 
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afterwards, when the content is frequently accessed. Replica Server components have content storage resources and are 
responsible for storing the content, e.g. in order to support time-shifted TV, CoD or other IPTV services. 

The content deployment component coordinates the delivery and storage resources of replica servers and establishes the 
optimal deployment policy for deploying content from content source to replica servers. It also controls the deployment 
of content among different replica servers. 

The content deployment component uses and maintains the deployment information about how the content is deployed 
among different replica servers. The content deployment component may use the information obtained from the request 
routing component or the load status of replica servers to optimize the deployment policy. 

The request routing component is responsible for directing client requests for content to appropriate replica servers and 
for interacting with the content deployment component to keep an up-to-date view of the content stored in the CDN. 

The content Delivery component works with Replica Server components and is responsible for streaming (e.g. via RTP 
over UDP) or downloading content to the UE. It also provides other functions, such as file downloading and uploading 
to and from the UE. 

The content Delivery component also handles control functions on the media during content delivery, including media 
control commands such as fast-forward, rewind, etc. 

The Accounting component, which maintains logs of client accesses and records the usage of the CDN. This 
information is used for traffic reporting and usage-based billing by the service or content Provider itself or by any other 
entities (e.g. a third-party billing organization). 

The content Preparation component may include: 

• Transcoding. 

• Other functions such as watermarking, ad-insertion into streams, format conversion, resolution conversion, etc. 

• Encryption. 

• Dividing a complete content file into smaller files with pieces of the content. 

The abstract components described above may be mapped to one or more logical functional entities. 
NOTE: A description of the Steps needed for CDN functionality is provided in annex A. 



4.3 Requirements 



4.3.1 CDN Functional Requirements 

4.3. 1 . 1 The CDN solution shall support both IMS-based and NGN Integrated IPTV subsystems. 

4.3.1.2 The CDN solution shall support content delivery for one or more multimedia systems. 

4.3.1.3 The CDN solution should support content delivery for more than one kind of multimedia service systems. 

4.3.1.4 The CDN solution shall support centralized and P2P content deployment. 

4.3.1.5 The CDN solution shall support automatic and manual publishing of the content. 

4.3.1.6 The CDN solution shall support automatic deployment of content from central content server to the edge 
content servers. 

4.3.1.7 The CDN solution shall provide support for the definition of different virtual deployment channels for different 
content providers. 

4.3. 1 .8 The CDN solution shall provide support for the definition of different virtual deployment channels for different 
service providers. 

4.3.1.9 The CDN solution shall support mechanisms to deploy content to a specific server or set of servers based on 
specific policies, e.g.: 
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• Deploy contents to the servers based on an estimation of the popularity of a specific content. 

• Deploy contents to the servers based on geographical location. 

• Deploy contents based on different user groups (e.g. hotel industry, school, white-collar community, rural 
groups, etc.). 

4.3.1.10 The CDN solution shall support content deployment via both pre-positioning of content and dynamic 
acquisition of content. 

4. 3. 1.11 The CDN solution should provide different priority levels for contents/services, and contents/services with 
high priority should be guaranteed when conflicts occurs between contents/services, e.g. when the bandwidth is not 
enough, the CDN should guarantee the QoS of high priority contents/services. 

4.3.1.12 The CDN solution shall provide mechanisms to collect and maintain the data related to the content deployment 
in order to allocate user's request to the appropriate servers. 

4.3.1.13 The CDN solution shall provide mechanisms to collect data related to the content popularity, (e.g. the number 
of user's requests, etc.). 

4.3.1.14 The CDN solution shall provide support for integration with an external alerting system. 

4.3.1.15 The CDN solution control entities shall have a view of the maximum/actual capacity of the delivery servers 
(e.g. number of users served, bandwidth, etc.) within the content delivery network. This information shall be organized 
and distributed to the control entities depending on the content delivery network topological organization. 

4.3.1.16 The CDN solution control entities shall be able to detect a change in the capacity of the content delivery 
servers within an organized group of server (e.g. a cluster or a set of clusters). The content delivery network control 
entities shall be able to notify other control entities in the content Delivery Network of these changes. 

4.3.1.17 The CDN solution control entities shall be able to detect a change in the availability of the content within a 
group of content delivery servers (e.g. a cluster or a set of clusters). Content delivery network control entities shall be 
able to notify other control entities in the Content Delivery Network as well as other entities in the service provider 
platform of changes in content availability and/or distribution. 

NOTE: The CDN solution control entities should make use of the information provided by other Content 

Delivery Network entities in determining their server or cluster assignment policy. The service platform 
Provider will process the request for a content item based on the latest updated content availability 
information in one or more Content Delivery Networks. 

4.3.1.18 The CDN solution Entities shall be able to detect an irregular signalling from the UE (e.g. irregular frequency 
of requests for content, unexpected messages, etc). The documentation of such irregular signalling is service provider 
dependent. The Content Delivery Network control entities shall be able to notify other control entities in the Content 
Delivery Network as well as other entities in the service provider platform of irregular signalling. 

4.3.1.19 The CDN solution shall support efficient content deployment, e.g. content segmentation mechanism (dividing 
the content file into smaller pieces). 

4.3.1.20 The CDN solution shall support content acquisition from different content providers. 

4.3.1.21 The CDN solution content deployment shall support a mechanism taking into account content aging (lifecycle 
of the content based on specific policy, e.g. LRU). 

4.3.1.22 The CDN solution shall support unicast and can optionally support multicast content delivery mechanism. 

4.3.1.23 The CDN solution should support CDN resources sharing between multiple service providers. 

4.3.1.24 The CDN solution shall be able to retrieve content from another CDN belonging to the same or a different 
service provider. 
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4.3.2 Functional Requirements for interconnecting a CDN witin an IPTV 
subsystem 

The following requirements apply when an IPTV subsystem is interconnected with a CDN: 

4.3.2.1 The CDN solution should provide mechanisms to request and acquire content from external systems based on 
the user's request. 

4.3.2.2 The CDN solution shall support mechanisms to select the content server for a specific user or set of users based 
on specific policies, for example: 

Pre-defmed content server. 

User location. 

User group. 

Content availability. 

Network traffic. 

4.3.2.3 The CDN solution shall support delivery of the content to the user through streaming, download and 
progressive download. 

4.3.2.4 The CDN solution shall support deployment and delivery of content protected by protection schemes in line 
withTS 187 003 [4]. 

4.3.2.5 The CDN solution shall support distribution of metadata related to the content. 

4.3.2.6 The CDN solution shall provide load balancing mechanisms among the servers, e.g. content servers, control 
servers, the criteria for balance the load can be: the network resources, e.g. network bandwidth, server capability and 
load, etc. 

4.3.2.7 The CDN solution shall support distribution and delivery of user generated content through 
upstreaming/upload mode. 

4.3.2.8 The CDN solution can optionally support forward error correction (FEC) or other retransmission mechanisms. 

4.3.2.9 The CDN solution should be capable of supporting enforcement of access control policies for content 
deployment and delivery (e.g. start time when content becomes accessible to user, end time when content stops being 
accessible to users, geo-locations for determining from where users can or cannot access content). 

4.3.3 CDN non-functional requirements 

4.3.3.1 The CDN solution should provide geographical scalability maintaining performances and effectiveness from a 
limited local area deployment to a more geographically distributed pattern. 

4.3.3.2 The CDN solution shall provide support for high availability (i.e. server mirroring, dynamic traffic forwarding, 

etc.). 

4.3.3.3 The CDN solution shall provide support for secure management and operations. 
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Content Delivery Network (CDN) functional 
architecture 



5.1 General description 



The Content Delivery Network (CDN) allows the optimization of the network use through a distribution of the content 
delivery servers in the physical network, and the optimization of the storage resources through mechanisms such as 
popularity-based distribution of the content on the content servers. Figure 5.1.1 shows the functional architecture of a 
CDN. 




Figure 5.1 .1 : Functional architecture of CDN 

The Content Delivery Network interfaces with IPTV service platforms, UEs, and content distribution systems. 

1) A Content Delivery Network offers two main interfaces to IPTV service platforms: 

A service control related interface: 

■ This interface is in charge of initiating the deUvery the requested content to the UE: This requires 
electing the best suited CDN cluster and content delivery server. 

A management related interface: 

■ This interface is in charge of administration and provisioning tasks. 

2) A Content Delivery Network offers two interfaces towards UEs: 

A content control related interface 
A media delivery interface: 

■ Delivery information is sent to the UE, after which delivery is initiated and completed by the UE. 
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NOTE 1 : Both the content control related and media delivery interfaces are reflected in the present document in 
order to fully describe the functions of the CDN interfaces with the UE. Further specification of these 
interfaces is not in the scope of the present document, as they are specified within the relevant IPTV 
service platforms, and in coordination with other standards organizations. 

3) A Content Delivery Network offers two interfaces towards content distribution systems: 

A service control related interface. 

A media delivery interface. 

NOTE 2: Both the service control related and media delivery interfaces are reflected in the present document in 
order to fully describe the functions of the CDN within a user-facing network. Specification of these 
interfaces outside of the TISPAN CDN is not in the scope of the present document, and will be 
coordinated with other standards organizations. 

5.2 Functional entities 

The Content Delivery Network contains one or more Content Delivery Functions (CDF) grouped geographically or 
administratively in clusters. The CDFs in one cluster are controlled by a specific Cluster Controller Function (CCF). 
One or more CCFs are controlled by the Content Delivery Network Controller Function (CDNCF). 

The CDF and CCF are directly involved in delivering content to the UE. The CDNCF controls content by interacting 
with the IPTV subsystem. 

The Asset Location Function (ALF) contains knowledge of content available to the CDN. 

The Content Origin Function (COF) provides content ingestion to the CDN. 

5.2.1 Content Delivery Network Controller Function (CDNCF) 

The Content Delivery Network Controller Function (CDNCF) is the function which manages one or more clusters. 

One or more CDN Controller Functions may coexist in the same CDN and may interact for the purpose of selecting the 
most appropriate cluster. 

There are two approaches with different outcomes for processing within the CDN when a request is received from the 
IPTV subsystem. 

• Service approach: In the first option the CDNCF sends the service control request to the selected CCF for 
further handling. Redirection to a CCF or to another CDNCF is also possible. 

• Query approach: In the second option the CDNCF returns the address of a CCF within the CDN to the IPTV 

sub-system. 

For either approach, the CDNCF queries the Asset Location Function (ALF) to provide a list of cluster(s) able to 
provide the requested content, and chooses the most appropriate cluster, based on local policy, from the list given by the 
ALF. Where the requested content is not available within the CDN or where the content is not optimally pre-positioned, 
the CDNCF and the ALF may coordinate to provide dynamic content acquisition. 

Tasks of CDNCF are: 

• Handling the unicast session establishment request from the IPTV sub-system (service approach) and 
forwarding the request to a selected CCF. 

• Handling the content query request from the IPTV sub-system (query approach) and answering with a CCF 
address to the IPTV sub-system to handle session establishment. 

• Retrieving network location of the UE from the unicast delivery request through interaction with appropriate 
functional element for that purpose (e.g. NASS or other location server). 

NOTE 1 : The network location of the UE may also be provided to the CDNCF by the IPTV service platform 
(e.g. in the case of IMS-based IPTV) as part of the unicast delivery request. 
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• Where appropriate, querying the ALF to provide a Hst of addresses composed of an arbitrary combination of: 

CCF address(es) and their CDNCF address(es). 

CDNCF address(es). 

The COF address having the requested content. 

• Selection of the best suited cluster (CCF) may be based on following criteria: 

Maximizing the probability of a cache hit in the selected cluster (e.g. by favouring a cluster that is known 
to have delivered the same content in the recent past). 

Content availability (e.g. according to its popularity rating, content may be available only on some CCF 
instances). 

Geographical location of the user and network proximity of the cluster to the UE (e.g. for optimization of 
network resources, the CDNCF may give preference to a CCF that is known to control CDFs located 
near the UE). 

Cluster delivery capability availability: The elected CCF must have the necessary delivery capability 
(i.e. at least one CDF under the control of the elected CCF should be available with the necessary 
delivery capability). 

Cluster status and cluster load (e.g. the CDNCF may favour a lightly loaded cluster over a highly load 
cluster). 

• Monitoring the status of CCF regarding content availability, delivery capability, cluster load, and user 
signalling. 

NOTE 2: User signalling monitoring can be used to check the operational integrity of the delivery and to prevent 
security attacks. It may also be used for targeted advertising. 

• Forwarding a content request to: 

a CCF from the cluster it manages having the content; 

a CCF, with the COF address for dynamic acquisition; or 

a CDNCF whose cluster have the requested content; or 

a CDNCF belonging to another CDN if no clusters within the CDN have the content. 

• May provide for forwarding, based on local policies, a content acquisition request received from the ALF to 
one or more CCFs 

NOTE 3: The CDNCF may choose to store the content acquisition request and forward it after a first user request 
for the content. 

• Controlling the content's update (duplication or deletion) between clusters. 

• Controlling the metering of content usage in clusters and the request for that content. 

• Report the metering information to another entity within CDN (ALF) or a third party outside of the CDN. 

5.2.2 Cluster Controller Function (CCF) 

The Cluster Controller Function (CCF) manages a set of content delivery functions (i.e. a cluster of CDFs). It is in 
charge of selecting the appropriate CDF within the cluster and controlling access from UE to the selected CDF. 

Tasks of CCF are: 

• Selecting the best suited CDF based on criteria which may include, but are not limited to: 

Content availability (e.g. depending on popularity rating, content may be available only on some CDF 
instances). 



£75/ 



1 7 ETSI TS 1 82 01 9 V3.1 .2 (201 1 -09) 

Geographic location of the user and network proximity of the CDF (e.g. for optimization of network 
resources, the CCF may give preference to the CDF nearest to the UE). 

Administrative considerations (e.g. based on service or user type). 

CDF deHvery capability availability (e.g. the selected CDF must support the necessary streaming 
capability. 

CDF status (e.g. the success or failure rate of responses; The CDF with higher success rate may be 
selected with priority. If the failure rate of a CDF in a statistical period exceeds a threshold, that CDF 
would be less likely to be selected for session requests). 

CDF load (e.g. the CCF may favour a lightly loaded CDF over a highly load CDF). 

Terminating IPTV service sessions. 

Selecting a CDF to acquire content on a request from the CDNCF. 

Optionally; Handling of content delivery control of CDF. 

Optionally; Proxying trick mode commands from the UE to the CDF. 

Sending a content acquisition request to the CDF to retrieve content from the COF 

Monitoring and maintaining information regarding the status of CDFs within its cluster. 

Reporting the status of the cluster regarding content availability, delivery capabiUty and user signalling to the 
CDNCF. 

Reporting of user media control actions (e.g. trick modes) invoked during a session (e.g. CoD). 

Reporting the status of the cluster regarding content availability to the ALE. 

Monitoring user signalling. 

NOTE: Monitoring of user signalling can be used to check the operational integrity of the delivery system, and to 
assist in providing security against attacks. It may also be used to facilitate targeted advertising. 

• Provide the metrics of the usage and request of the content that is stored in CDFs of the cluster, such as UE's 
identifier, content copy identifier, content issuer, number of content requests in a specific period, etc. 

• Controlling for the content's update (duplication or deletion) within the cluster. 

5.2.3 Content Delivery Function (CDF) 

Tasks of Content Delivery Function (CDF) are: 

• Handling content delivery (for delivering multimedia content to user). 

• Reporting status to CCF (e.g. reporting on load status). 

• Reporting content availability to CCF (e.g. content has been acquired or deleted). 

• Handling trick mode commands from the UE. 

• Reporting of user media control actions (e.g. trick modes) invoked during a session (e.g. CoD). 

• In the case of interconnection with an IMS-based IPTV system, IPTV service action data shall be exchanged to 
report user media control actions when the IPTV service requires the use of IPTV service action data, as 
described in clauses 8.4.5.2 and 8.4.5.3 of TS 182 027 [2]. 

• Retrieving content from the COF or another CDF following a CCF request. 

• Retrieving and sharing content from a COF or a CDF from another CDN belonging to the same or different 
service provider, following a CCF request. 
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5.2.4 Asset Location Function (ALF) 



The Asset Location Function is a functional entity having the knowledge of the available content, the content location 
and others content parameters (e.g. category, popularity, size, media type, generator source, etc.). Having these 
parameters allows the ALF to provide a cluster list to the CDNCF, which will select an appropriate cluster to deliver 
content to the UE. 

The ALF is also in charge of selecting the best CDNCF to ingest content available on the COF. 

The tasks of the Asset Location Function (ALF) are: 

• Monitoring content availability within the CDN. 

• Receiving notifications regarding content availability on the COF. 

• Requesting a CDNCF to acquire content available on the COF. 

NOTE 1 : The criteria for selection of the appropriate CDNCF(s) are out of scope of the present document. 

• Answering to the CDNCF with a list composed of an arbitrary combination of: 

CCF address(es) and their CDNCF address(es). 

CDNCF address(es). 

COF address having the requested content. 

NOTE 2: The COF address should be returned when the content is not available within any CDN known by the 
ALF. 

5.2.5 Content Origin Function (COF) 

The Content Origin Function is a functional entity in charge of content ingestion. 




Figure 5.2.5.1 : COF elementary functions 

The COF functional entity is composed of two elementary functions: 

• C-COF (Control plane COF) whose task is handling content ingestion signalling, such as: 

Processing content ingestion signalling from an Asset preparation function. 

NOTE 1 : The Asset preparation function is out of scope of the present document. 

Notifying the ALF that a new content is available on the COF and conveying associated information 
(e.g. how the content is to be accessed on the COF, deployment policy such as whether the content needs 
to be pre-positioned). 

• D-COF (Data plane COF) whose tasks are: 

Acquiring content from an Asset preparation function. 
Delivering content to a CDF when the CDF requests it. 
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NOTE 2: How new content is acquired by the COF is out of scope of the present document. 

5.3 Overall architecture and reference points 

Figure 5.3.1 is an overall view of the TISPAN CDN architecture, showing the functional elements and reference points. 
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Figure 5.3.1 : Overall view of CDN architecture 

Reference points shown in figure 5.3.1 are specified in clause 6 of the present document. 

NOTE: Implementation of the CDN architecture may utilize multiple topologies, as described in annex C. 

The relationship between the IPTV subsystem and the CDN, as well as the relationship and interconnection between 
multiple TISPAN CDNs are depicted in following clauses, annexes B and D. 

5.4 Relationship between IPTV subsystem and CDN 

The relationship between CDN and IMS-based IPTV, NGN integrated IPTV subsystem may be realized as shown in 
figure 5.4.1. The IPTV subsystem may be an IMS-based or NGN integrated subsystem. 
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Figure 5.4.1 : Relationship between IPTV subsystem and CDN 

There are two approaches to mapping the CDN to the IPTV subsystem. The difference between the two approaches is 
that realization of the service approach is entirely through the Cu reference point to the CDNCF, while the query 
approach uses a separate reference point, Ct, for communicating with the CCF, in addition to the Qc (or Cu) reference 
point towards the CDNCF. 

NOTE 1: It is assumed that the IPTV subsystem MF is replaced by the CDN. 

NOTE 2: When the core IMS is used, i.e. for an IMS-based IPTV subsystem, signalling between any 2 nodes 
involving the IPTV subsystem, CDNCF, and CCF goes through the IMS core. 

For detailed mapping of the CDN to the IMS-based IPTV and NGN Integrated IPTV subsystems, see annex B. 

5.5 Interconnection between two TISPAN CDNs within the 
same service provider domain 

There may be more than one CDN interconnected with the IMS-based and NGN Integrated IPTV subsystem. In this 
case, the IPTV subsystem will have to determine (via pre-configuration or application logic) the CDNCF entry point. 
Figure 5.5.1 shows an example of the interconnection between two TISPAN CDNs. 
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ALF 




Figure 5.5.1 : Example interconnection between two TISPAN CDNs 

NOTE: CDN Interconnection between different service provider domains is addressed in annex D. 



6 Reference points 

6.1 CDNCF - CCF (Ys) 

This reference point between CDNCF and CCF allows the CDNCF to hand over a content request to a specific CCF 
selected by the CDNCF using the local policy and the list of addresses where the content is available provided by the 
ALF. It also allows each CCF to report the status of the cluster regarding content availability, delivery capability and 
user signalling. This allows the CDNCF to enhance its user redirection and CCF selection mechanisms. 

The CDNCF also uses this reference point to request a CCF to acquire content. 



6.2 CCF - CDF (Yp) 



This reference point between CCF and CDF is used for CCF to control content delivery flow. It also allows CDF status 
reporting to the CCF and the CCF to request a CDF to acquire content. 



6.3 CCF - UE (Xc') 



This reference point between CCF and UE is used to exchange content control messages for controlling the IPTV 
content flow, (i.e. trick mode commands in case of streaming). 
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NOTE: The Xc' reference point performs the same tasks with the reference point Xc (TS 182 027 [2] and 

TS 182 028 [3]), the difference is Xc connected to MCF (TS 182 027 [2] and TS 182 028 [3]), but the Xc' 
connected to CCF. 



6.4 CDF - UE (Xc") 



This optional reference point between CDF and UE is used to exchange content control messages for controlling the 
IPTV content flow, i.e. trick mode commands. 

NOTE 1: The Xc" reference point performs the same tasks with the reference point Xc (TS 182 027 [2] and 

TS 182 028 [3]), the difference is Xc connected to MCF (TS 182 027 [2] and TS 182 028 [3]), but the Xc" 
connected to CDF. 

NOTE 2: This reference point is useful in case offloading the CCF function from trick play command proxying. 
This would enhance the CCF performance and availability. 

6.5 CDF - UE (Xd') 

This reference point between CDF and UE is used to deliver the content to UE. 

NOTE: The Xd' reference point performs the same tasks with the reference point Xd (TS 182 027 [2] and 

TS 182 028 [3]), the difference is Xd connected to MDF (TS 182 027 [2] and TS 182 028 [3]), but the Xd' 
connected to CDF. 



6.6 CDNCF-CDNCF(Yq) 



The Yq reference point is used to allow a CDNCF to proxy a request to another CDNCF for handling. This reference 
point may exist between two CDNCFs belonging to different TISPAN CDNs. 



6.7 CDF-CDF (Cf) 



The Cf reference point between CDF and CDF allows delivering content between the two CDFs for content 
distribution. The CDF is always instructed where to go to acquire content. This reference point may exist between two 
CDFs belonging to different TISPAN CDNs. 

6.8 CDNCF - IPTV subsystem (Cu) 

The Cu reference point between CDNCF and IPTV subsystem carries IPTV service control signalling originating from 
the IPTV subsystem to CDNCF. 

6.8.1 CDNCF - IMS-based IPTV subsystem 

In the case of an IMS-based IPTV subsystem, the Cu reference point performs the same tasks as the reference point y2 
(TS 182 027 [2]). The difference is that y2 connected to the MCF (TS 182 027 [2]), but Cu is connected to a CDNCF. 

6.8.2 CDNCF - NGN integrated IPTV subsystem 

In the case of an NGN Integrated IPTV subsystem, the Cu reference point performs the same tasks as the reference 
point Sa (TS 182 028 [3]). The difference is that Sa connected to the MCF (TS 182 028 [3]), but Cu is connected to a 
CDNCF. 



6.9 CDNCF - IPTV subsystem (Qc) 



The Qc reference point between CDNCF and IPTV subsystem allows the IPTV subsystem to query the CDNCF for the 
CCF to be contacted for content. 
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6.10 CCF - IPTV subsystem (Ct) 

The Ct reference point between CCF and IPTV subsystem carries IPTV service control signalling originating from the 
IPTV subsystem to CCF. 

The selected CCF must fulfil the request or return an error. Redirection or relay outside the CDN is not supported. 

6.1 0.1 CCF - IMS-based IPTV subsystem 

In the case of an IMS-based IPTV subsystem, the Ct reference point performs the same tasks as the reference point y2 
(TS 182 027 [2]). The difference is that y2 connected to MCF (TS 182 027 [2]), but Ct is connected to CCF. 

6.1 0.2 CCF - NGN Integrated IPTV subsystem 

In the case of an NGN Integrated IPTV subsystem, the Ct reference point performs the same tasks as the reference point 
Sa (TS 182 028 [3]). The difference is that Sa connected to MCF (TS 182 028 [3]), but Ct is connected to CCF. 



6.11 CDNCF-ALF(Qq) 



The Qq reference point between CDNCF and ALF allows the CDNCF to query the ALF about the addresses having the 
requested content. The Qq reference point allows the ALF to ask the CDNCF to instruct the CCF to acquire content 
after receiving a request from the COF. This reference point also allows the CDNCF to query the content's other 
parameters (e.g. category, popularity, size, media type, generator source, etc.) from the ALF, and allows the CDNCF to 
request the ALF to ingest content. 



6.12 ALF- ALF (Qq') 



The Qq' reference point between ALFs allows one ALF to query another about the addresses having the requested 
content. It can be considered a subset of the Qq reference point between CDNCF and ALF. This reference point may 
exist between two ALFs belonging to different CDNs. 



6.13 ALF- CCF (Yy) 



The Yy reference point between ALF and CCF allows the CCF to send information on the content availability of the 
clusters, and may also be used by the CCF to query the content's parameters (e.g. category, popularity, generator source, 
etc.) from the ALF. The CCF may also utilize the Yy reference point to verify content management permissions with 
the ALF. 



6.14 ALF- OOF (Yv) 



The Yv reference point between ALF and COF allows the COF to notify the ALF that content is available. This 
reference point also allows the ALF to request the COF to ingest content. 

6.15 COF -CDF (Of) 

The Cf reference point between COF and CDF is used to deliver content between CDF and the content origin function. 
The CF' reference point may also be used by the CDF to deliver content (e.g. UGC) to the COF for ingestion in the 
CDN, or to the COF of another CDN. 

6.16 COF- COF (Cf) 

The Cf reference point between two separate COFs is used to deliver content between two content origin functions. 
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7 



Procedures 



NOTE: In the following clauses, when the core IMS is used, i.e. for an IMS-based IPTV subsystem, signalling 
between any 2 nodes involving the IPTV subsystem, CDNCF, and CCF goes through the IMS core. 



7.1 



Request routing within CDN 



This procedure describes all possible outcomes within CDN for routing a session. The routing procedure can be invoked 
from any CDN session establishment procedure that requires CDN request routing support to deliver the requested 
content to a UE. This applies to both IMS-based and NGN Integrated IPTV subsystems. 

Request routing within CDN results in one of potentially several outcomes. They are as follows: 

• The first configured CDNCF locates a CDF to fulfil the requested content. If the content is not available on the 
selected CDF, the CDF needs to acquire the content in real-time from the COF. 

There are several sub-options related to real-time content acquisition from the COF: 

• The first configured CDNCF proxies the request to another CDNCF. 

• The first configured CDNCF redirects the request to another CDNCF. 

NOTE: The above are the outcomes for a single CDNCF decision; these same outcomes are also applicable in a 
recursive manner whenever another CDNCF is invoked. 

The following clauses describe detailed procedures for each of the possible session routing outcomes. Although the 
interactions show a single interface between the IPTV subsystem and the first CDNCF, the description handles both the 
Cu, and Qc interfaces as depicted in the architecture (figure 5.3.1) for interaction between the IPTV subsystem and the 
first CDNCF. 

7.1 .1 CDN request routing resolves to a CDF - content available 

The procedure below shows the case where the configured CDNCF selects a CDF to serve the requested content. 
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Figure 7.1 .1 .1 : CDN routing - CDF located with content available 

The following is a summary of the steps involved in this procedure: 

1) The IPTV subsystem initiates a request to the first configured CDNCF (CDNCFl). 
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2) CDNCFl locates a CCF that can fulfil the content request. In this case CCFl is located. If the request from the 
IPTV subsystem does not require the simultaneous establishment of a delivery session, the procedure jumps to 
step 7 and the address of the selected CCF is included in the response. 

3) CDNCFl forwards the request to CCFl . 

4) CCFl locates a CDF that can fulfil the content request. In this case, CDFl is located. 

5) Either the CCFl establishes a delivery session to the selected CDFl and the delivery session information is 
returned to the IPTV subsystem; or the address of selected node, CCFl (in step 2), together with other 
information is returned to the IPTV subsystem and delivery session establishment step is not performed. 
Hence, the procedure terminates at step 2 and a response is returned accordingly. 

6) CCFl returns a response to CDNCFl. 

7) CDNCFl returns a response to the IPTV subsystem. 

7.1 .2 CDN request routing resolves to a CDF - dynamic acquisition 

In some scenarios, the content may not yet be available on the selected CDF. In these scenarios, dynamic acquisition of 
the content is triggered into the CDN. There are three cases that are considered here for such dynamic acquisition. In the 
first case, depicted in clause 7.1.2.1, the CCF triggers early dynamic acquisition before establishing the delivery 
session. In the second case, depicted in clause 7.1.2.2, the CCF triggers late dynamic acquisition when the UE initiates 
the delivery initiation request to actually start streaming the content. It is assumed here that media control signalling 
transits through the CCF. The third and final case, depicted in clause 7.1.2.3, is similar to case 2, the difference being 
that media control signalling does not transit through CCF and as a result it is the CDF that triggers late dynamic 
acquisition. 

7.1 .2.1 CDN request routing resolves to the CDF - early dynamic acquisition 

The procedure below shows the case of early dynamic acquisition, and where the requested content is located in the 
COF. In this case, the CDNCF instructs a CCF to download the content from the COF before the delivery session is 
established. The content will be retrieved from the COF and (after delivery initiation is requested by the UE) will be 
streamed simultaneously to the end-user. It is important that content retrieved from the COF by the CDF be faster than 
streaming to the end user to avoid buffer starvation and bad end-user experience. 
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Figure 7.1 .2.1 .1 : CDN request routing Resolves to CDF -Early Dynamic Acquisition 

The following is a summary of the steps involved in this procedure: 

1) The IPTV subsystem initiates a request to the first configured CDNCFl. 

CDNCFl locates a CCF that can fulfil the requested content. In this case the content is not located in any CCF. 

CDNCFl queries ALF for a node that can fulfil the requested content. 

ALF returns a response including the COF as the only node which can fulfil the requested content. 



2) 
3) 
4) 



5) CDNCFl consults its local policies and decides to instruct a CCF for dynamic acquisition of the content from 
the COF. 

6) The selected CCF, in turn, selects a CDF and orders it for dynamic acquisition of the requested content from 
the COF. 

7) The selected CDF starts dynamic acquisition of the content from the COF. 

If the request from the IPTV subsystem does not require the simultaneous establishment of a delivery session 
to be established the procedure jumps to step 10 and the address of the selected CCF (CCFI) is included in the 
response. 

8) CCFI establishes a delivery session to the selected CDF and the delivery session information is returned to the 
IPTV subsystem, as well as the address of the selected CCF (CCFI). 

9) CCFI returns a response to CDNCFl including the session delivery information and the address of the 
selected CCF (CCFI). 

10) CDNCFl returns a response to the IPTV subsystem. 
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11) CDFl reports to CCFl successful acquisition of content. 

12) CCFl reports to ALF successful acquisition of the content by CDFl. 

7.1 .2.2 CDN request routing resolves to CDF - late dynamic acquisition triggered by 

CCF 

The procedure below shows the case for late dynamic acquisition, triggered by the CCF. It is assumed that the media 
control signalling is proxied through the CCF. 
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Figure 7.1.2.2.1 : CDN request routing resolves to CDF - late dynamic acquisition triggered by CCF 

The following is a summary of the steps involved in this procedure: 

1) Steps 1 to 4 are identical to the steps 1 to 4 in clause 7. 1 .2. 1 . If the request from the IPTV subsystem does not 
require the simultaneous establishment of a delivery session, the procedure jumps to step 7 and the address of 
the selected CCF node (CCFl) is included in the response. 

2) In step 5, CCFl establishes a delivery session for the selected CDF and the delivery session information is 
returned to the IPTV subsystem; as well as the address of the selected CCF node (CCFl). 

3) In step 6, CCFl returns a response to CDNCFl. 

4) In step 7, CDNCFl returns a response to the IPTV subsystem. 
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5) In step 8, session delivery is established, only for the case when no delivery session was previously 
established. 

6) In step 9, the UE initiates content delivery to start streaming the content. 

7) In step 10, the CCF to instruct the CDF to start dynamic acquisition of the content. 

8) In step 11, the CCF proxies the content delivery initiation request to the CDF. 

9) In step 12, the selected CDF starts dynamic acquisition of the content from the COF. 

10) In step 13 and 14 the content delivery initiation acknowledge response is proxied back to the UE via the CCF. 

11) In step 15, CDFl reports to CCFl successful acquisition of content. 

12) In step 16, CCFl reports to ALF successful acquisition of the content by CDFl. 

7.1 .2.3 CDN request routing resolves to CDF - late dynamic acquisition triggered by 

CDF 

The procedure below shows the case of late dynamic acquisition, triggered by the CDF. It is assumed that the media 
control signalling is NOT proxied through the CCF. 



IPTV 
Subsystem 



CDNCF-1 



CCF-1 



CDF-1 



-1. Request for Content^ 



2. Locate CCF 



No CCF. Located 



Consult CDN 
policies 



-S.Query- 



■A. Response (COF)- 



5. Establish Delivery Sessipn as 
per steps 5 to 7 in section 7.6.1 



-6.Response- 



-7. Response— 



8.1 Establish Delivery Session as per steps 5 to 7 in 
section 7,6,1 



9, Delivery Initiation Requ^st- 



1 1, Delivery Initiation Request Acknowledge- 



CDNCF-2 



CCF-2 



CDF-2 



COF 



10, CDF starts fetching content ftom COF 



12, Report Successfiil content Caching 



13, Report Successfiil content Caching 



Figure 7.1.2.3.1 : CDN request routing resolves to CDF - late dynamic acquisition triggered by CDF 

The procedure steps in this case are similar to those in clause 7.1.2.2, the difference being the absence of the equivalent 
to step 10 in figure 7.1.2.2.1. 
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NOTE: There are several options that can be deployed to allow CDFl to know the location where it can acquire 
the requested content when it does not have a local copy. For example, CDFs can be configured with a 
well-known COF address for that purpose, and the COF can subsequently redirect the CDF acquisition 
request to the appropriate server. Alternatively the URL received by the CDF can include the appropriate 
addressing information (or an appropriate handle allowing the CDF to use configured addressing 
information) for that purpose. 



7.1 .3 CDN request routing resolves to a redirect to a new CDNCF 

The procedure below shows the case where a CDF able to fulfil the request could not be located by the configured 
CDNCF, and where instead, a redirect to another CDNCF is returned to the IPTV subsystem. This case is only 
applicable when the incoming request from the IPTV subsystem to the CDNCF does not require the simultaneous 
establishment of a delivery session. 




COF 



Consult CDN 
policies 

(4) Response 

■"(Redirect to new - 

CDNCF) 



(6) Request for Content 



(8) Response 



(7) CDNCF2 

Repeats same steps 

as CDNCFl 



Figure 7.1.3.1 : CDN request routing - redirect to a new CDNCF 

The following is a summary of the steps involved in this procedure: 

1) The IPTV subsystem initiates a request to the first configured CDNCF (CDNCFl). 

2) CDNCFl attempts to locate a CCF that can fulfil the request. In this case no CCF can be located. 
CDNCFl queries ALF for a node that can fulfil the requested content. 



3) 
4) 

5) 



ALF returns a response including a list of CDNCFs, in addition to other lists of nodes that can fulfil the 
requested content. 

CDNCFl consults its local policies and decides to redirect the IPTV subsystem to a new CDNCF node 
(CDNCF2) selected from the list of nodes returned from the ALF. Hence CDNCFl returns a response to the 
IPTV subsystem to that effect. 

6) IPTV subsystem issues a new request to CDNCF2. 
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7) CDNCF2 repeats the same procedure as CDNCFl and one of the main outcomes discussed in clause 7.1.2 can 
result. A delivery session is established (specified in the service approach) and session delivery information is 
included in the session initiation response. 

8) CDNCF2 returns a response to IPTV subsystem. The response includes the appropriate information for the 
service Approach and NGN Integrated IPTV. 

7.1 .4 CDN request routing resolves to a proxy of the original request to a 
newCDNCF 

The procedure below shows the case where a CDF to fulfil the request content could not be located by the configured 
CDNCF, and instead a new CDNCF is selected, and the original request is proxied to the newly selected CDNCF node. 



IPTV 

Subsystem 



CDNCFl 



(l)Request For 
Content • 



CCFl 



CDFl 



ALF 



CDNCF2 



CCF2 



CDF2 



COF 



(2) Locate CCF 



No CCF located 



(3)Query_ 



(4) Response (List of CDNCFs) 



Consult CDN 
policies 



(5) Request for Content_ 



(8) Response_ 



(7) Response_ 



(6) CDNCE2 

Repeats same steps 

as CDNCH 



Figure 7.1.4.1 : CDN request routing - proxy to a new CDNCF 

The following is a summary of the steps involved in this procedure: 

1) The IPTV subsystem initiates a request to the first configured CDNCF (CDNCFl). 

2) CDNCFl attempts to locate a CCF that can fulfil the request. In this case no CCF can be located. 

3) CDNCFl queries ALF for a node that can fulfil the requested content. 

4) ALF returns a response including a list of CDNCFs, in addition to other lists of nodes, which can fulfil the 
requested content. 

5) CDNCF consults its local policies and decides to proxy the incoming request to a CDNCF node (CDNCF2) 
selected from the list of nodes returned from ALF. Hence CDNCFl proxies the request to CDNCF2. 
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6) CDNCF2 repeats the same procedure as CDNCFl and one of the main 3 outcomes discussed in clause 7.1 can 
result from that. In the service approach, a delivery session is established and session delivery information is 
included in the session initiation response. In the case where the request from the IPTV subsystem requires the 
immediate establishment of a delivery session, the response included in the session initiation response includes 
session delivery information as well as the selected CCF node. If the request from the IPTV subsystem does 
not require the simultaneous establishment of a delivery session only the address of the selected CCF is 
included in the session initiation response. 

7) CDNCF2 returns a response to CDNCFl . 

8) CDNCFl returns a response to the IPTV subsystem. 

7.1 .5 CDN request routing for unicast content download 

The initial request from the IPTV subsystem shall include an indication to distinguish a content download session from 
a content streaming session. 

For content download sessions, each node in the CDN, based on its internal policies, may decide to return its address to 
the IPTV subsystem, or locate another node that can service the request. 

As such, the address of a CDNCF, or the address of a CCF or address of a CDF can be returned to the IPTV subsystem, 
similar, where applicable, to the flows in figures 7.1.1.1 to 7.1.4.1 and subsequently to the UE, except that for unicast 
content download, no delivery session is established. 

The call flow in figure 7. 1 .5. 1 shows the case where the address of a CCF is returned. The steps in figure 7. 1 .5. 1 are the 
same as call flow in figure 7.1.4.1, except for steps 5 and 6. 



IPTV 

Subsystem 



CDNCFl 



CCFl 



CDFl 



ALF 



CDNCF2 



CCF2 



CDF2 



COF 



(l)Request For 
- Content » 



(2) Locate CCF 



No CCF located 



_ (3) Query 



(4) Response (List of CDNCFs , etc) 



Consult CDN 
policies 



(8) Response 



(5) Proxy the request 



(6) l,ocate CCF 



(7) Address of CCF 2_ 



Figure 7.1.5.1 : CDN request routing for unicast content download 
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7.2 Request initiation: service approach - CDNCF sends IPTV 
request to CCF 

7.2.1 Service approach: common procedures 

7.2.1 .1 Unicast streaming session Initiation - service approach 

The following sequence depicts the procedure for unicast streaming delivery. 



UE 



IPTV Subsystem 



CDNCF 



CCF 



CDF 



(1) Initiation Request 



(2) Initiation Request 



(3) Perform the procedure in section 7.1. The outcome in 
this case is based on the outcome depicted in 7.1.1 where 
CDNCF resolves to a CCF and the CCF resolves to a CDF 



](4) Initiation Response 



(5) Initiation Response 



(6) Content Delivered to UE 



Figure 7.2.1.1.1 : Unicast streaming session initiation procedure - service approach 

1) The UE initiates a CoD related request to the IPTV subsystem. 

2) The IPTV subsystem sends an initiation request to CDNCF. 

3) In this case, the CDNCF follows the procedure specified in clause 7.1.1 and a CCF is being selected to fulfil 
the request. Then the CCF selects a CDF and set up the delivery session. CCF returns the delivery information 
to the CCF. 

4) CDNCF returns the delivery information to the IPTV subsystem in a session initiation response. 

5) The IPTV subsystem includes the deliver information in an initiation response to the UE. 

6) The UE then performs content delivery. 
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7.2.1 .2 Service approach: CDNCF query to ALF 



UE 



IPTV Subsystem 



-1, Content Request ► 



-5, Content Response— 



-2. Initiation Request— 



3.CDNCF performs the routing in section 7.1 including the establishment of a 
delivery session with the selected CDF 



-4. Initiation Response- 



-6. Content Delivery( Download or Unicast or Downstream> 




Figure 7.2.1.2.1 : Content delivery for IPTV request (service approach) 

1) The UE initiates a content request which contains the content identifier and the UE's location information (e.g. 
the IP address) to the IPTV subsystem. 

2) The IPTV subsystem initiates a request to the CDNCF for the location of the optimal CDF for delivery of the 
requested content for the UE. 

3) The CDNCF performs the necessary routing as specified in clause 7.1. 

4) The CDNCF in this example returns the address of a CDF to the IPTV subsystem. 

5) The IPTV subsystem returns the information (e.g. URL) of the selected CDF to the UE. 

6) The requested content is delivered to the UE from the selected CDF. 

7.2.2 Service approach: additional procedures for IMS-based IPTV 
subsystem 

7.2.2.1 Unicast streaming session initiation (no session delivery established) 

This clause describes the common CDN implications for processing the UE initiated unicast streaming service 
described in clause 8.4.1.1.1, and the SCF initiated unicast streaming service described in clause 8.4.1.1.2 of 
TS 182 027 [2]. Figure 7.2.1.1.1 outlines the different steps and messages exchanged between the CDN elements 
(CDNCF, CCF and CDF). It also outlines the CDN message exchange with the SCF, IMS CORE and UE. 
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CORE IMS 



SCF 



CDNCF 



CCF 



CDF 



1 . UE initiated CoD Session Initiation as per steps 
1 to 4 in ciause 8.4.1.1.1 in [2] 




2. Session initiation , 
Request 



3. CCF 
Selection 



. Session initiation RequesH 



49. Session initiation Response- 



10. Session initiation_ 
Response 



1 1 . Session initiation response and resource 
commit as per steps 9 to 11 in ciause 8. 4. 1.1.1 in 
J21 



5. CDF 
Selection 



6. Deliver session 
setup Request 



8. Deliver session 
setup Response 



7.; Media Deiivery 
res<iurces assignment 



Figure 7.2.2.1.1 : Unicast streaming session initiation procedure 

1) The UE initiates a dialogue to the CoD service. The session initiation request is routed by the Core IMS 
entities up to the SCF in charge of the requested CoD service. The SCF performs service authorization as 
described in clause 5.1 in TS 182 027 [2]. The details of this step are described in steps 1 to 4 in 

clause 8 .4. 1 . 1 . 1 in TS 1 82 027 [2] . 

2) If the UE is allowed to access the content, and the service delivery requires unicast streaming, the SCF 
forwards the session initiation request which contains the SDP that carries the UE's IP address information to 
the CDNCF. 

NOTE 1: There may be several CDNCFs in the CDN architecture. The SCF is assumed to choose one of them 
based on service policies. Those policies are provider dependent and are out of scope of the present 
document. 

NOTE 2: Figure 7.2.1.1.1 indicates the UE initiated unicast streaming session procedures. It also could be used for 
SCF initiated because there is no difference between them with respect to the CDN. 

3) The CDNCF selects a specific CCF according to the policies described in clause 5.2.1. If the Geographical 
location of the UE is used as a criteria for selecting the appropriate CCF, the CDNCF may obtain geographic 
information for the UE according to UE's IP address contained in the SDP from the session initiation request, 
and then select the appropriate CCF as an initial target. 

4) The CDNCF forwards the session initiation request to the selected CCF. 

5) The CCF selects a specific (CDF) according to the policies described in clause 5.2.2. 

6) The CCF sends a delivery session setup request, for the requested content, to the selected CDF, and establishes 
a binding between the UE initiated session request and the corresponding delivery session. 
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7) The CDF performs delivery resource allocation according to the delivery session setup request. 

8) If the CDF successfully completes the delivery resource allocation, the CDF sends a delivery session setup 
response to the CCF. It contains content control and media delivery channel information. If the CDF fails to 
complete the delivery resource allocation, the CDF returns an error message to the CCF and the CCF may send 
the delivery session setup request to another CDF. 

If the CDF's status is used as criteria for selecting the appropriate CDF by CCF, the number of total delivery 
sessions and the number of successes or failures in a statistics period for the CDF may be maintained and 
updated by CCF. The maintained data is used for selecting appropriate CDF in next period. 

9) The CCF sends a session initiation response to the CDNCF. It contains content control and media delivery 
channels information. The CCF may alter the content control and media delivery information to receive the 
streaming control commands from the UE (i.e. the CCF would act in that case as a proxy for streaming control 
commands). 

10) The CDNCF relays the session initiation response to the SCF. 

11) The SCF relays the session initiation response to the UE through the IMS Core. The IMS Core may perform 
network resource commit for the media delivery and control channels. This step is equivalent to steps 46 to 48 
in clause 8.4. 1.2.2 in TS 182 027 [2], or steps 9 to 11 in clause 8.4.1.1.1 inTS 182 028 [3]. 

7.2.2.2 UE initiated unicast streaming session modification for IMS based IPTV 

This clause describes the CDN implications for processing a UE initiated unicast streaming session Modification 
described in clause 8.4.2.0A of TS 182 027 [2]. 

Session modification is used to assign or renegotiate one or more content control and/or delivery channels in a session. 

Figure 7.2.2.3.1 outlines the different steps and messages exchanged between the CDN elements (CDNCF, CCF and 
CDF). It also outlines the CDN message exchange with the SCF, IMS CORE and UE. 
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UE 



Core IMS 



SCF 



(1) UE initiated CoD 
Session IVIodification as per 
steps 1 to 3 in Clause 
8.4.2.0AinTS182 027 



(3) CDN internal 
routing of 
request as 
described in 
Clause 7.1 



CCF 



CDF 



(2) Session Modification Req. 



i9) Session Modification 
Response 



(10) Session Modification 
response and resource 
commit as per steps 6 to 8 
in Clause 8.4.2.0A in TS 
182 027 



(3) Session Modification 



Or Initiation Request 



i. 



Session Modification Or 



nitiation Response 



(4) CDF 
selection 



(5) Delivery Session Setup Re quest 



(7) Delivery Session Setup Reijlons^ 



If needed: initiate teardown of 
existing content delivery channels 
and associated sessions 



If needed: initiate teardown of 
existing content control and delivery 
channels and associated sessions 



(6) Media 

Delivery resources 
assignment 



Figure 7.2.2.2.1: UE initiated unicast streaming session modification procedure 

1) The UE initiates a dialogue to the CoD service. The session modification request is routed by the core IMS 
entities up to the SCF in charge of the requested CoD service. The SCF performs service authorization as 
described in clause 5.1 in TS 182 027 [2]. The details of this step are described in steps 1 to 3 in 

clause 8.4.2.0A in TS 182 027 [2]. 

2) If the UE is allowed to modify the session, and the SCF forwards the session modification request to the 
CDNCF selected during session initiation (clause 7.2.1.1). 

3) If the session modification does not involve content control channel assignment or renegotiation the CDNCF 
forwards the session modification request to the CCF selected in session initiation. If the session modification 
involves content control channel assignment or renegotiation the CDNCF selects a specific CCF and forwards 
the request to it. In the latter case the forwarded request is equivalent to a session initiation. 
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4) The CCF selects a specific CDF according to the policies described in clause 5.2.2 and to the session 
modification (or initiation requirements). 

5) The CCF sends a delivery session setup request, for the requested content, to the selected CDF, and establishes 
a binding between the UE initiated session request and the corresponding delivery session. 

6) The CDF performs delivery resource assignment according to the delivery session setup request. 

7) The CDF sends a delivery session setup response to the CCF. It contains content control and media delivery 
channels information. 

8) The CCF sends a session modification or initiation response to the CDNCF. It contains content control and 
media delivery channels information. The CCF may alter the content control and media delivery information 
to receive the streaming control commands from the UE (i.e. the CCF would act in that case as a proxy for 
streaming control commands). 

NOTE 1 : If the session modification is a replacement of a set of existing content delivery channels by another set of 
content delivery channels. The CCF initiates the teardown of the former set of channels and their 
associated sessions. 

9) The CDNCF relays the session modification response to the SCF. 

NOTE 2: If the session modification is a replacement of a set of existing content control delivery channels by 

another set of content control and delivery channels. The CDNCF initiates the teardown of the former set 
of channels and their associated sessions. 

10) The SCF relays the session modification response to the UE through the Core IMS. The core IMS may 
perform network resource commit for the media delivery and control channels. This step is equivalent to 

steps 9 to 1 1 in clause 8 .4. 1 . 1 . 1 in TS 1 82 027 [2] . 



7.2.2.3 



CDN initiated unicast streaming session modification for IMS based IPTV 



This clause describes the CDN implications for processing a CDN initiated unicast streaming session Modification 
described in clause 8.4.2.0B of TS 182 027 [2]. 

Session modification is used to assign or renegotiate one or more content control and/or delivery channels in a session. 

Figure 7.2.2.3.1 outlines the different steps and messages exchanged between the CDN elements (CDNCF, CCF and 
CDF). It also outlines the CDN message exchange with the SCF, IMS CORE and UE. 



UE 



Core IMS 



SCF 



CDNCF 



CCF 



CDF 



(1) Session Modification Req. 



(2) Session Modification Req. 



(3) equivalent to MP 
initiated CoD Session 
Modification as in steps 2 
to 3 of Clause 8.4.2. OB in 
TS 182 027 



(4) Session Modification request procedure as described in Clause 7.2.2.2 



Figure 7.2.2.3.1 : CDNCF initiated unicast streaming session modification procedure 

The CCF initiates a session modification request routed by the Core IMS entities up to the SCF in charge of the ongoing 
CoD session. The SCF performs authorization as described in clause 5.1 in TS 182 027 [2]. 
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The CDNCF forwards the session modification request to the SCF. 

The SCF forwards the session modification request to the UE through the CORE IMS (equivalent to steps 2 and 3 in 
clause 8.4.2.0B in TS 182 027 [2]). 

If the UE accepts the session modification it performs the procedure described in clause 7.2.2.2. 

NOTE: A similar procedure is applied in case of CDNCF and CDF initiated session modifications. 

7.2.2.4 SCF initiated unicast streaming session modification for IMS based IPTV 

This clause describes the CDN implications for processing an SCF initiated unicast streaming session Modification 
request. Session modification is used to assign or renegotiate one or more content control and/or delivery channels in a 

session. 

The SCF initiates a session modification request routed by the Core IMS entities up to the UE. 

If the UE accepts to the session modification it performs the procedure described in clause 7.2.2.3. 

NOTE: In some implementations the UE may not be allowed to refuse a session modification request issued by an 
SCF unless there is a technical or compatibility reason (codecs, negotiated protocols implementation, 
etc.). 

7.2.2.5 Restricted (forced-playout policies) 

The procedure for forced playout policies (restricted trickplay) of a content item has the same procedures as depicted in 
clause 7.2.1.1, with the following differences. 

Step (2) The IPTV subsystem sends a session initiation request to CDNCF, and also indicates the content shall have 
restricted playback. The restriction indicates the following type of restrictions, including, but not limited to: 

• no fast-forward permitted; 

• no ability to seek within the content (only applies to forward direction); 

• no ability to seek beyond the content (e.g. next segment; only applies to forward direction); 

• no ability to seek backward in the content. 

Step (6) The UE will have trickplay content delivery restricted according to what was indicated in step (4). The 
following actions take place when attempting the indicated restrictions: 

• if no fast-forward permitted then change to normal speed when reaching content; 

• if no ability to seek within the content then reject request to seek within content; 

• if no ability to seek beyond the content then the search is limited to the range from beginning to current 
segment of the content; 

• if no ability to seek backward in the content then the search is limited to forward (depending on forward 
constraints). 

The change in delivery characteristics only impacts the communication between the CDF and UE. The CCF may or 
may not proxy the communication. If a media is being fast-forwarded and a specific content does not allow fast-forward 
then the CDF shall announce change in speed to the UE. 

The change in available speeds for a content item is not necessarily informed to the UE. The request to fast-forward in a 
restricted content may simply be rejected. 
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7.2.3 Service approach: additional procedures for NGN integrated IPTV 
subsystem 

7.2.3.1 UE initiated unicast streaming session initiation - coupled mode 

Figure 7.2.3.1.1 provides an overview of the information flows for content delivery flow for NGN integrated IPTV. 
UE I I RACS I CDNCF I CCF I I CDF I IPTV Control UPSF/IUDF SD&S/CFIA 



(1) Multimedia content on demand (CoD) session procedureD Step 1-7 



(2) Cop Delivery seledition 



(3) Resource Keservation 



(4) Conter^t Location Request 



(5) CDNCF performs the procedure in 7.1 
tiiat results in delivery information 
including the address of selected CCF 
being returned to the IPTV control . 



(6) Cof^tent Location 



Response 

(7) MejJia and control Channels Initiation Response 



1) 

2) 
3) 

4) 
5) 



Figure 7.2.3.1 .1 : Content delivery flow for NGN integrated IPTV 

The UE initiates a dialogue to the CoD service as described in steps 1 to 7 in clause 11.2 of TS 182 028 [3]. 

UE initiates a request to the IPTV control for content delivery. 

IPTV Control selects CDNCF based upon operator defined criterions, then requests RACS to allocate 
resources between the end-points. Distributed RACS interfaces are allowed. 

IPTV Control initiates a content location request to the selected CDNCF. 

In this example, the CDNCF performs the procedure defined in clause 7.1.1 and returns the address of the 
selected CCF as well as the session delivery information for the requested content. 



NOTE: Other routing cases from 7.1 can apply and will result in a different call flow. 

6) The content location response returned to the IPTV control includes the address of the CCF as well as the 
session delivery information. 

7) The IPTV Control returns the session initiation response to the UE, including the session delivery 
information, and the address of selected CCF. 
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7.3 Request initiation: query approach - CDNCF sends CCF 
address to IPTV 

This clause depicts the procedures where IPTV subsystem will take the "query approach" to locate the target cluster for 
the content request, within the CDN, the "query approach" may be taken between CDNCF and ALF to locate a specific 
CDNCF for the content request. 

The "query approach" is applicable for both IMS IPTV subsystem and NGN Integrated IPTV subsystem, i.e. the 

message pair of "Query request" and "Query Response" may be implemented on either IPTV subsystem 

(see clause 7.3.1). For more information of IPTV subsystems, TS 182 027 [2] and TS 182 028 [3] maybe referenced. 

7.3.1 Query approach: common procedures 
7.3.1 .1 Query approach: CDNCF (ALF) query 

The call flows depict the setup for a content delivery channel using the query approach. 



UE 



IPTV Subsystem 



-1, Content Request ► 



CCF 



-6. Content Response— 



-2. Query Request P[ 



3. Session Routing performed as per section 7.1. The address of a CCF is retiuned 



-4, Query Response— 



5. IPTV Subsysterrr sets up a content delivery cliarmel session 



-7. Content Delivery( Download or Unicast or Downstream)— 



Figure 7.3.1.1.1 : Content delivery for IPTV request via query approach 

1) The UE initiates a content request which contains the content identifier and the UE's location information 
(e.g. the IP address) to the IPTV subsystem. 

2) The IPTV subsystem requests from the CDNCF the location of the optimal CCF for delivery of the 
requested content for the requested UE. 

3) The CDNCF performs the necessary routing as specified in clause 7.1 and returns the address of a CCF to 
the IPTV subsystem. 

4) The CDNFC returns the address of the selected CCF to the IPTV subsystem. 

5) The IPTV subsystem proceeds to set up the content delivery channel. 

6) Once the content delivery channel is successfully established, the IPTV subsystem returns the necessary 
information to the UE. 
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7) The requested content is delivered to the UE from the selected CDF. The mode of content delivery may be 
download or unicast or downstream or whatever that is supported by both the UE and CDF. 

7.3.1 .2 Unicast streaming Initiation - query approach 

The following sequence depicts the procedure for unicast streaming deUvery using the query approach. 



UE 



IPTV Subsystem 



CDNCF 



CCF 



CDF 



(1) Content Request 



(2) Content Location Request 

! ^ 



(3) Perform the procedure in section 7.1. 



(4) Content Location Response 



^ 



(5) Content Request 



(7) Content Response 



(6) Content Delivery 
Setup 



(8) Content Response 



(9) Content Delivered to UE 



Figure 7.3.1.2.1 : Unicast streaming initiation procedure - query approach 

1) The UE initiates a content request to the IPTV subsystem. 

2) The IPTV subsystem requests from the CDNCF the location of the optimal CCF for delivery of the content 
(the request does not require setting up a delivery service). 

3) In this case, the CDNCF follows the procedure specified in clause 7.1.1 and a CCF is being selected to fulfil 
the request. 

4) The address of CCF is returned in the content location response to the IPTV subsystem. 

5) The IPTV subsystem sends a content request to CCF. 

6) CCF establishes content delivery to the CDF. 

7) CCF returns the content delivery information to the IPTV subsystem. 

8) The IPTV subsystem includes the content delivery information in a response to the UE. 

9) The UE then performs content delivery. 



7.3.1.3 



Restricted (forced-playout) policies 



The procedure for forced playout policies (restricted trickplay) of a content item has the same procedures as depicted in 
clause 7.3.1.2 unicast streaming, with the following differences. 
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Step (5) The IPTV subsystem sends a content request to the CCF, and also indicates that the content shall have 
restricted playback. The restriction indicates the type of restrictions including but not limited to: 

• no fast-forward permitted; 

• no ability to seek within the content segment (only applies to forward direction); 

• no ability to seek beyond the content (e.g. next segment; only applies to forward direction); 

• no ability to seek backward in the content. 

Step (9) The UE will have trickplay content delivery restricted according to what was indicated in step (5). The 
following actions take place when attempting the indicated restrictions: 



• 



• 



if no fast-forward permitted then change to normal speed when reaching content; 

if no ability to seek within the content then reject request to seek outside or within content; 

• if no ability to seek beyond the content then the seek is limited to the beginning of content; 

• if no ability to seek backward in the content then the seek is limited to forward. 

The change in delivery characteristics only impacts the communication between the CDF and UE. The CCF may or 
may not proxy the communication. If a media is being fast-forwarded and a specific content does not allow fast-forward 
then the CDF shall announce change in speed to the UE. 

The change in available speeds for a content item is not necessarily informed to the UE. The request to fast-forward in a 
restricted content may simply be rejected. 

7.4 Media control procedures 

7.4.1 Unicast streaming delivery - trick play commands - proxy via CCF 

This clause describes the procedures for delivering the content for the unicast streaming initiation described in 
clause 7.3.1.2, where Trick play commands are conveyed through the CCF. The following steps are depicted in 
figure 7.4.1.1. 
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UE 



(1) Delivery initiation request (Play) 



(4) Delivery initiation request acknowledge 



(5) Unicast Streanning Media Flow 



(6) Delivery trick play command (Play/Pause/Fast Forward/Rewind) 



(9) Delivery trick play command acknowledge 



CCF 



CDF 



(2) Delivery initiation request 



(3) Delivery initiation request acknowledge 



(7) Delivery trick play command 



(8) Delivery trick play command acknowledge 



(10) Unicast Streaming Media Flow altered or interrupted according to trick play command 



(Play) 



Figure 7.4.1.1 : Unicast streaming delivery procedure with CCF as a proxy to tricit play commands 

1) The UE sends a delivery initiation request to the CCF to obtain the unicast stream. 

2) The CCF checks if the UE is allowed to issue that request and if so relays the message to the preselected CDF 
(the selection procedure is described in clause 7.3.1.2). 

3) The CDF acknowledges the delivery initiation request to the CCF. 

4) The CCF relays the acknowledgement to the UE. 

5) The CDF starts sending the unicast stream to the UE according to the delivery parameters that were 
negotiated in clause 7.3.1.2. 

NOTE: The following steps (6 to 10) may be initiated by the UE at any point in time after the delivery has been 
initiated and before it is terminated. 

6) The UE sends a trick play command request (Pause, Play, Fast Forward, Rewind) to the CCF. 

7) The CCF checks if the UE is allowed to issue that request and if so relays the message to the preselected CDF 
(the selection procedure is described in clause 7.3.1.2). 

8) The CDF acknowledges the trick play request to the CCF. 

9) The CCF relays the acknowledgement to the UE. 

10) The CDF alters the flow depending on the trick play request. 



£75/ 



44 



ETSI TS 182 019 V3.1.2 (2011-09) 



7.4.2 Unicast streaming delivery - \r\ck play commands - direct to CDF 

This clause describes the procedures for dehvering the content as a resuh for unicast streaming Initiation described in 
clause 7.3.1.2 where Trick play commands are sent directly to the CDF. The following steps are depicted in 
figure 7.4.2.1. 



UE 



CDF 



(1) Delivery initiation request (Play) 



(2) Delivery initiation request acknowledge 



(3) Unicast Streaming IVIedia Flow 



(4) Delivery trick play command (Play/Pause/Fast Forward/Rewind) 



(5) Delivery trick play command acknowledge 



(6) Unicast Streaming Media Flow altered or interrupted according to trick play command 



Figure 7.4.2.1 : Unicast streaming delivery procedure witli 
direct UE-CDF tricit play command interaction 

1) The UE sends a delivery initiation request to the CDF to obtain the unicast stream. 

2) The CDF checks if the UE is allowed to issue that request and if so acknowledges the delivery initiation 
request. 

NOTE 1 : How the CDF acquires the trick-play policy and/or performs the check is out scope of the current release. 

3) The CDF starts sending the unicast stream to the UE according to the delivery parameters that were 
negotiated in clause 7.3.1.2. 

NOTE 2: The following steps (4 to 6) may be initiated by the UE at any point in time after the delivery has been 
initiated and before it is terminated. 

4) The UE sends a trick play command request (Pause, Play, Fast Forward, Rewind) to the CDF. 

5) The CDF checks if the UE is allowed to issue that request and if so acknowledges the trick play request. 

6) The CDF alters the flow depending on the trick play request. 
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7.5 Upload/upstream generic procedures 

The CDN may be utilized for network content storage. After the UGC is uploaded to the CDN, the UGC owner may 
access and download the UGC from the CDN. 

Figure 7.5.1 provides an overview of the information flows for UGC based content delivery procedure. 



UE 



IPTV Subsystem 



CDF 



-1. Upload/Upstream RequesH 



45. Upload/Upstream Response— ^ 



-2. Upload/Upstream Request- 



COF 



3.CDNCF selects a CCF; CCF selects a CDF. 



-*1. Upload/Upstream Response—^ 



6.Upload/Upstream from UE to CDF. CDF may further upload/upstream to COF. 



^8. Upload Report- 



-7. Upload Report ^ 



-9. Update the Database-^ 



Figure 7.5.1 : Content upload/upstream procedure 

1) The sequence is triggered by an action from the user. The user requests upload/upstream content which 
result is an upload/upstream content request from UE to the IPTV subsystem. 

2) The IPTV subsystem forwards the upload/upstream request to the CDNCF. 

3) A CDF is selected to receive the upload/upstream content (The method of selecting an appropriate CDF 
under the routing process of ALF/CDNCF/CCF/CDF is described in clause 7.1). 

NOTE 1 : The process of selecting the target cluster and CDF for upload/upstream may be based on content 

attributes (e.g. size, media types, etc.) and/or the CDF capability (e.g. CDF status, delivery capability, 
etc.) as depicted in clause 5. 

4) The CDNCF sends the upload/upstream response to the IPTV subsystem. 

5) The IPTV subsystem forwards the upload/upstream response to the UE. 

6) Content is uploaded/upstreamed from the UE to the CDF. The CDF may further upload/upstream to the COF 
if required. 

NOTE 2: Whether the content may be uploaded/upstreamed to COF is managed by the ALE, according to the 
policies needed for the service. 

7) The CDF provides reports to the CCF for the content upload/upstream. 

8) The CCF provides reports to the CDNCF for the content upload/upstream. 

9) The CCF sends new content storage information to the ALF, which updates the content identifier and 
location information appropriately. 
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NOTE 3: The CCF shall report to the ALF for all uploaded/upstreamed content received from the UE, and the ALF 
shall maintain the location information for all the uploaded/upstreamed content. 

7.6 Generic download procedures 

This clause depicts the download procedures for either the IMS-based IPTV subsystem or NGN Integrated IPTV 
subsystem (see clauses 7.6.2 and 7.6.3). The interfaces associated with the CDN entities are universal to either IPTV 
subsystem. For information on the IPTV subsystems, refer to TS 182 027 [2] and TS 182 028 [3]. 

7.6.1 Unicast download/downstream common procedures 
7.6.1 .1 Unicast download delivery - redirect to CDF mode 

The Redirect to CDF delivery mode procedure is shown in figure 7.6.1.1.1. 



UE 



CDF 



(1) Delivery initiation request (Download) 



(2) Delivery initiation response (download) 



Figure 7.6.1.1.1 : Unicast download delivery procedure - redirect to CDF mode 

The Unicast download delivery procedure, in redirect to CDF mode, consists of the following steps: 

1) The UE initiates delivery initiation request to the CDF. 

2) The CDF replies with a delivery initiation response containing the requested content. 

In case of a redirect from the CDF the UE shall update the session in case it is further redirected while attempting 
delivery. 

NOTE: The advantage of this mode is that the delivery latency is reduced to minimum. The disadvantage is that 
the CCF has no real time awareness of the progress of the delivery and it is up to the UE to indicate to the 
CCF when the delivery is done or when a redirection to another CDF has occurred. 

7.6.1 .2 Unicast download delivery - CCF proxy redirect mode 

The CCF proxy redirect delivery mode procedure is shown in figure 7.6. 1 .2. 1 . 
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UE 



CCF 



(1) Delivery initiation request (Download) 



(6) Delivery initiation response (download) 



CDF1 



(2) Delivery initiation request (Download) 



(3) Delivery initiation Redirect (CDF2) 



CDF2 



(4) Delivery initiation request (Download) 



(5) Delivery initiation Redirect (CDF3) 



CDFn-1 



(2n-1) Delivery initiation Redirect (CDFn) 



(2n) Delivery initiation request (Download) 



(2n+1) Delivery initiation response (download) 



CDFn 



Figure 7.6.1.2.1 : Unicast download delivery procedure - proxy redirect mode 

The unicast download delivery procedure, in proxy redirect mode, consists of the following steps: 

1) The UE initiates delivery initiation request to the CCF. 

2) The CCF forwards the delivery initiation request to CDFl. 

3) If CDFl is unable to deliver the content, it replies with a delivery initiation redirect response indicating that 
the request should be redirected to another CDF. 

4) The CCF forwards the delivery initiation request to CDF 2. 

5) If CDF2 is unable to deliver the content, it replies with a delivery initiation redirect response indicating that 
the request should be redirected to another CDF. 

6) Steps 4 and 5 can be reiterated until a CDF (i.e. CDFn) is able to deliver the requested content. 

7) The CCF relays the response from the CDF able to deliver content, to the UE. 

7.6.1 .3 Unicast download delivery in CCF triangular proxy Mode 

The CCF triangular proxy delivery mode procedure is shown in figure 7.6.1.3.1. 
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UE 



(1 ) Delivery initiation request (Download) 



(3) Delivery initiation response (download) 



CCF 



Change source of 
request so that it 
appears to be the UE 



CDF 



(2) Delivery initiation request (Download) 



Figure 7.6.1 .3.1 : Unicast download delivery procedure - CCF triangular proxy mode 

The unicast download delivery procedure, CCF triangular proxy mode consists of the following steps: 

1) The UE initiates delivery initiation request to the CCF. 

2) The CCF forwards the delivery initiation request to the CDF. Before sending the request over the network the 
CCF alters the request so that the source would be the UE (or the NAT where the request originated from). 

3) The CDF replies with a delivery initiation response containing the requested content directly to the UE as if 
the request was issued from the UE. 

NOTE: The advantage of this mode is that the CCF has real time awareness of the progress of the delivery 
without being in copy of the contents. 

7.6.1 .4 Unicast download delivery in redirect mode 

The redirect mode procedure for unicast content download delivery is shown in figure 7.6. 1 .4. 1 . 



UE 



(1) UE perforr|is 
procedures, 

the CDNCF 



and 



CDNCF 



CCF 



content selection 

gets the URI pointing to 



(2) Delivery request 



(3) Delivery redirection response 



(4) Delivery request 



(5) Delivery redirection response 



(6) Delivery request 



(7) Delivery response with the cent 



3nt. 



CDF 



(8) CDF delivery status report 



Figure 7.6.1.4.1 : Unicast download delivery procedure - redirect mode 
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The unicast download delivery procedure, in redirect mode consists of the following steps: 

1) The UE get the CDNCF's URI pointing to the CDNCF from the content selection procedures as described in 
IMS based IPTV architecture [2] and NGN Integrated IPTV subsystem architecture [3], and then the UE 
continue the following procedures. 

2) The UE initiates delivery request to the CDNCF, and carries the content identifier of the content to be 
downloaded. 

3) The CDNCF selects a specific CCF and replies UE with the redirection response carrying the address of the 
selected CCF. 

4) Then the UE initiates delivery request to the CCF, and carries the content identifier of the content to be 
downloaded. 

5) The CCF selects a specific CDF and replies UE with the redirection response carrying the address of the 
selected CDF. 

6) The UE initiates delivery request to the CDF, carries the content identifier. 

7) The CDF responds to UE containing the requested content. 

NOTE: The CCF and CDF can act as one cluster, and returns the content to UE. 

8) The CDF reports the content delivery status to CCF on the completion of the delivery, e.g. CDF reports that 
the requested content- 1 is successfully delivered to UE. 

7.6.2 Unicast download/downstream session initiation for IMS based IPTV 

This clause describes the processing for a UE -initiated unicast download service described in clauses 8.18.1 and 8.18.2 
of TS 182 027 [2]. The procedures for UE-initiated content download and SCF initiated content download service are 
included in this clause. Figure 7.6.2.1 outlines the different steps and messages exchanged between the CDN elements 
(CDNCF, CCF and CDF). It also outlines the CDN message exchange with the SCF, IMS CORE and UE. 



£75/ 



50 



ETSI TS 182 019 V3.1.2 (2011-09) 



UE 



CORE IMS 



SCF 



CDNCF 



CCF 



CDF 



1. UE or SCF initiated Session Initiation 
Procedures Steps as in TS 182 027 Clause 
8.18.1 steps 1 and 2 or 8.18.2 step 1 



2. Session initiation 



Request 



3. CDN internal routing of request as described in Clause 7.1 



4. Media content download delivery channel establish as described in TS 182 027 Clause 8.18.2 step 3 



5. Session initiation 



Response 



6. Session initiation response as in TS 182 
027 Clause 8.18.1 steps 6-8 or TS 182 027 
Clause 8.18.2 step 4 



7. unicast download content delivery 



Figure 7.6.2.1: UE initiated unicast download session initiation procedure 

1) The UE or SCF initiates a dialogue for unicast content download service: 

a) For UE initiated unicast content service, this step is the same as the UE session initiation procedure in 
TS 182 027 [2] clause 8.18.1 steps 1 and 2. 

b) For SCF initiated unicast content service, this step is the same as SCF session initiation procedure in 
TS 182 027 [2] clause 8.18.2 step 1. Depending on the order in which the SCF sends out the session 
initiation requests, step 2 may proceed step 1 or be executed in parallel. 

2) The SCF forwards the session initiation request to the selected CDNCF for unicast download service. 

NOTE: The initiation request is authorized by SCF for UE initiated unicast download service and the UE makes 
logical check as the step 2 in clause 8.18.2 of TS 182 027 [2]. 

3) The CDN internal request routing is performed as in clause 7.1. In this example the address of a CDF is 
returned. 

4) The address of CDF is returned in a response to the SCF. 

5) The session initiation response is returned to the UE as in TS 182 027 [2] clause 8.18.1 steps 6-8 for 
UE-initiated unicast download service, or as in TS 182 027 [2], clause 8.18.2 step 4 for SCF-initiated unicast 
download service. 

6) UE initiates the content download delivery request to the CDF. 
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7.6.3 Unicast download/downstream initiation for NGN integrated IPTV 

In general, the procedures for download/downstream initiation are same as clause 7.6.2 for either IPTV subsystem. 

Comparing the procedures in two IPTV subsystems, it is the SCF in the IMS based IPTV subsystem, and the "IPTV 
Control" entity in the NGN integrated IPTV subsystem, which provide initiation signalling with the CDNCF. 



7.7 



Termination procedures 



This clause depicts the termination procedures involving the IPTV subsystem and CDN. 

Clause 7.7.1 gives the generic termination procedures that are applicable on either the query approach or service 
approach on CDN routing mechanism. 

Clause 7.7.2 gives the additional termination procedures of query approach on either IPTV subsystem. 

Clause 7.7.3 gives the additional termination procedures for the IMS based service approach. If to implement the 
termination procedures on NGN integrated IPTV subsystem, the interface between IPTV subsystem and CDN would be 
the same while the corresponding entity in the NGN integrated IPTV subsystem to connect the CDNCF will be the 
entity of "IPTV control" rather than SCF in IMS based IPTV subsystem. 



7.7.1 



Generic termination procedures 



7.7.1 .1 UE-lnltiated termination 

The following sequence depicts the procedure for UE initiated termination for unicast streaming. 



UE 



IPTV Subsystem CDNCF 



CCF 



CDF 



1 . Termination Request 



-^ 



2. Terminate the Content Delivery 



5. Termination Response 



Figure 7.7.1.1.1: UE-initiated termination 

1) The UE initiates termination towards the IPTV subsystem. 

2) The IPTV subsystem, in turn, initiates a content delivery termination towards the CCF, which in turn 
initiates a content delivery termination towards the CDF. 

3) The IPTV subsystem returns to the UE the termination response. 

7.7.1 .2 IPTV subsystem-initiated termination 

The following sequence depicts the procedure for IPTV subsystem initiated termination of unicast streaming. 
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UE 



IPTV Subsystem CDNCF 



CCF 



CDF 



1. Termination Request/Response 



2. Terminate the Content Deiivery 



Figure 7.7.1.2.1 : IPTV subsystem-initiated termination 

1) The IPTV subsystem initiates termination towards the UE. 

2) The IPTV subsystem initiates the termination to the CCF for content delivery, which in turn initiates 
termination to the CDF for content delivery. 

7.7.2 Additional termination procedures - query approacii 
7.7.2.1 CCF initiated termination - query approach 

The following sequence depicts the procedure for CCF triggered termination of unicast streaming. 



UE 



IPTV Subsystem 



CDNCF 



CCF 



CDF 



1. Content Delivery Termination 



2. Delivery Termination Announcement 



3. Content Delivery Termination Request 



-^ 



4. Content Delivery Termination Response 



5. Termination Request/Response 



Figure 7.7.2.1.1: CCF initiated termination 

1) The CCF imitates content delivery termination towards the CDF. 

2) The CCF announces to the IPTV subsystem that delivery is terminated. 

3) The IPTV subsystem initiates the content delivery termination towards the CCF. 

4) The CCF reports to the IPTV subsystem the content delivery termination response. 

5) The IPTV subsystem also initiates termination towards the UE. 
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7.7.2.2 



CDF initiated termination - query approach 



UE 



IPTV Subsystem 



CDNCF 



CCF 



CDF 



7. Session termination request/ 
response 



1. Session Delivery termination Announcem 

^^ 1 



2. Session Delivery termination Announcement 

1^ 1 1 

I I I 

3. Content Delivery session termination Request 4 Content 
[ [ ^|_Delivery Session 

I I I Termination 

5. Content Delivery Session termination response Request 

1 1 6. Content 

[ 'Delivery Session_ 

I I Termination 

I I response 



^ 



Figure 7.7.2.2.1 : CDF initiated termination (query approachi) 

1) The CDF announces to the CCF that the content delivery is terminated. 

2) The CCF announces to the IPTV subsystem that the content deHvery is terminated. 

3) The IPTV subsystem initiates the content delivery termination towards the CCF. 

4) The CCF initiates the content delivery termination towards the CDF. 

5) The CCF reports to the IPTV subsystem the content delivery termination response. 

6) The CDF reports to the CCF the content delivery termination response. 

7) The IPTV subsystem also initiates termination towards the UE. 

7.7.3 Additional termination procedures - service approach - IMS-based 
subsystem 

7.7.3.1 CCF initiated session termination - IMS-based service approach 

The following sequence depicts the procedure for CCF triggered termination of unicast streaming using the service 
approach. 
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UE 



IMS Core 



SCF 



CDNCF 



CCF 



CDF 



1 . Terminate the Content 
Delivery Session 



2. Session Termination 



3^ Session Termination 



Request 



Request 
4. Session Termination 



Repsonse 



5. Session Termination 



6. Session Termination and 
response 



Repsonse 



Figure 7.7.3.1.1 : CCF initiated session termination (service approach) 

1) CCF and CDF terminate the content delivery session. The CCF SHALL issue a termination request to the 
CDF, after the CDF terminates the media delivery session, it SHALL response to CCF. 

2) CCF initiates session termination request to CDNCF. 

3) CDNCF forwards the session termination request to SCF. 

4) SCF responds to CDNCF. 

5) CDNCF forwards the response to CCF. 

6) SCF initiates session termination to UE via IMS Core and UE responds. 

7.7.3.2 CDF initiated session termination - IMS-based service approach 



UE 



IMS Core 



SCF 



CDNCF 



CCF 



CDF 



1. Announce Session 
Termination 



2. Session Termination 



3. Session Termination 



Request 



Request 
4. Session Termination 



Repsonse 



5. Session Termination 



6. Session Termination and 
response 



Repsonse 



7. Terminate the Content 
Delivery Session 



Figure 7.7.3.2.1 : CDF initiated session termination (service approach) 

1) The CDF announces to the CCF that the content delivery session is terminated. 

2) CCF initiates session termination request to CDNCF. 
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3) CDNCF forwards the session termination tequest to SCF. 

4) SCF responds to CDNCF. 

5) CDNCF forwards the response to CCF. 

6) SCF initiates session termination to UE via IMS core and UE responds. 

7) CCF and CDF terminates the content delivery session. The CCF SHALL issue a termination request to CDF, 
after CDF tears down the media delivery session, it SHALL response to CCF. 



7.7.3.3 



UE initiated session termination (IMS-based service approach - CCF proxy 
mode) 



UE 



IMS Core 



SCF 



CDNCF 



CCF 



CDF 



1. Session Termination Request as as per 
steps 1 - 3 in clause 8.4.3.1 in [2] 



2. Session Terminatiori 



Request 



3. Session Termination 



6. Session Termination 



Request 



Request 










4.Terminate the Content 
Delivery Session 


5. Session Termin 


ation 






"" Response 







7. Session Termination response as as per step 
7 in clause 8.4.3.1 in [2] 



Figure 7.7.3.3.1 : UE initiated session termination (llUIS-based service approach /CCF proxy mode) 

1) UE initiates termination request to SCF via IMS core as defined in TS 182 027 [2]. The details of this step are 
described in steps 1 to 3 in clause 8.4.3.1 in TS 182 027 [2]. 

2) SCF sends session termination request to CDNCF to request to terminate the unicast streaming session. 

3) CDNCF forwards the session termination request to CCF. 

4) The CCF terminates the content delivery session on the CDF. 

5) CCF responds to CDNCF. 

6) CDNCF forwards the response to SCF. 

7) SCF forwards the response to UE via IMS Core as defined in TS 182 027 [2]. The details of this step are 
described in step 7 in clause 8.4.3.1 in TS 182 027 [2]. 

NOTE: This procedure may also apply in the case of an IMS subsystem-initiated termination. 

7.7.3.4 SCF initiated session termination - IMS-based service approach 

This is the SCF initiated session termination, the session termination request sent to CDN and UE by SCF. 



£75/ 



56 



ETSI TS 182 019 V3.1.2 (2011-09) 



UE 



IMS Core 



SCF 



CDNCF 



CCF 



CDF 



1. Session Termination 
Request 



2. Session Termination 



Request 



3. Terminate Content Delivery 
Session 



4. Session Termination 
5. Session Termination Response 



Request 



. Session Termination Request as as per 
steps 3 - 7 in clause 8.4.3.2 in [2] 



Figure 7.7.3.4.1 : SCF initiated session termination (service approach) 

1) SCF sends session termination request to CDNCF to request to terminate the unicast streaming session. 

2) CDNCF forwards the session termination request to CCF. 

3) CCF terminates the content DeUvery session. 

4) CCF responds to CDNCF. 

5) CDNCF forwards the response to SCF. 

6) SCF sends a session termination request to UE and UE responds as defined in TS 182 027 [2]. The details of 
this step are described in steps 3 to 7 in clause 8.4.3.1 in TS 182 027 [2]. 

7.8 Content management procedures within CDN 

This part describes the procedures for content ingestion and deployment in the CDN. 

7.8.1 Content ingestion Procedures 
7.8.1 .1 Procedures for pre-positioning 
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Figure 7.8.1.1 .1 : Content pre-positioning 
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1) The COF may be externally trigger to retrieve content. 

2) The content is acquired by the COF. 

NOTE: How the COF acquires the content is out of scope. 

3) COF issues a content ingestion notification to the ALF when a new media content has been acquired. 

4) ALF answers to the notification. 

7.8.1 .2 Procedures for dynamic acquisition 

Content ingestion through dynamic ingestion is covered in clause 7.1.2. 

7.8.2 Content deployment procedures 

7.8.2.1 Receiver driven pre-positioned content deployment 

This clause describes the procedures for content ingestion for within CDN when pre-positioning is triggered by the 
receiver. 
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Figure 7.8.2.1.1 : Receiver driven pre-positioned content deployment 
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1) ALF selects one or several CDNCF(s) to get the content. 

2) ALF sends a content deployment request to the selected CDNCF(s). 

3) CDNCF enforces specific content deployment policy and selects one or multiple clusters to receive the 
content. 

4) CDNCF sends content deployment request to the CCF of the selected cluster(s). 

5) CCF selects on or multiple CDFs according to specific deployment policy to receive the content. 

6) CCF forwards the request to selected CDFs. 

7 to 9) CDF responds to CDNCF and then it forwards to ALF that the content could be deployed into the selected 
CDF. 

10) Receiver driven data acquisition content is transferred between COF and CDF. 

11) Content deployment notification to the CDF after receiving the content. 

12) Content deployment notification response from the CCF to the CDF. 

13) CCF issues content updating notification to ALF. 

14) ALF responds to the notification. 

7.8.2.2 Sender driven pre-positioned content deployment 

This clause describes the procedures for content deployment within the CDN when content pre-positioning is triggered 
by the sender. 
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Figure 7.8.2.2.1 : Sender driven pre-positioned content deployment 

1) ALF selects one or several CDNCF(s) to get the content. 

2) ALF sends a content deployment request to the selected CDNCF. 

3) CDNCF enforces specific content deployment policy and selects one or multiple clusters to receive the 
content. 

4) CDNCF sends content deployment request to the CCF of the selected cluster(s). 

5) CCF selects on or multiple CDFs according to specific deployment policy to receive the content. 

6 to 7) CCF answers to CDNCF and then it forwards to ALF that the content could be deployed into the selected 
CDF. 

8) Sender driven data acquisition content is transferred between COF and CDF. 

9) Content deployment notification to the CDF after receiving the content. 

10) Content deployment notification response from the CCF to the CDF. 

11) CCF issues content updating notification to ALF. 

12) ALF responds to the notification. 
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7.9 Content replication within the CDN 

The CDNCF periodically monitors the content usage within clusters and makes storage adjustments to enable high 
availability of CDN service. 

Content copies that are rarely requested during a given time range are removed from the CDF, while content that is 
frequently requested within a time range will be duplicated onto another CDF in order to increase availability. 

7.9.1 Duplication of content copy within cluster 
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Figure 7.9.1 .1 : Duplication of content copy within cluster 

1) An (optional) external or internal trigger is sent to CCF fcir initiating the duplication of content copy. 

2) The CCF selects an appropriate CDF in the same cluster as the CDF-2 and requests the CDF-1 to duplicate 
that content copy and deliver a copy to CDF-2. 

3) The CCF requests the CDF-1 to duplicate that content copy and to deliver a copy to another CDF (CDF-2) 
within the same cluster. 

4) The CDF-1 duplicates and delivers a copy to the CDF-2. 

5) The CDF-1 responds to the CCF of the content copy's duplication. 

6) The CCF sends new content storage information to the ALF which updates the location and other parameters 
appropriately. 

7) The CCF notifies the CDNCF for the duplication. 
NOTE: Steps 2 through 5 may be conducted repeatedly. 
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7.9.2 Duplication between two clusters under the same CDNCF 
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Figure 7.9.2.1 : Duplication of content copy between two clusters under the same CDNCF 

1) An (optional) external or internal trigger is sent to CDNCF for initiating the duplication of content copy. 

2) The CDNCF (optionally) sends the metrics request to the CCF for acquiring the statistics of request for the 
content in a time range. 

3) If step 2 occurs, the CCF returns the CDNCF the record of usage information of that specific content that may 
contain the UE's identifier, content copy identifier(s), content issuer and the number of content requests in the 
specific period. 

4) If the CDNCF judges that the content is frequently requested in that specific period and the total number of 
requests for that copy of that content is greater than a threshold (in terms of the distribution and the request 
frequency of the requesting UEs for that content), the CDNCF determines whether to duplicate the copy to 
another cluster or within the same cluster. If it is to duplicate and deliver content to another cluster also under 
the control of CDNCF itself, the CDNCF selects the CCF(CCF-2) which controls a proper cluster to receive 
and maintain the duplicate copy. 

5) CDNCF sends the duplicate request to the selected CCF-2. 

6) CCF-2 selects an appropriate CDF (CDF-2) to receive and maintain the duplicate copy. 

7) CCF-2 returns the duplication response which contains the information of the selected CDF (CDF-2) to 
CDNCF. 

8) CDNCF selects a CCF(CCF-l) and the selected CCF(CCF-l) selects an appropriate CDF(CDF-l) that will 
duplicate and deliver the content copy to the CDF-2. 

9) Content delivery: 

For push mode; CCF-1 will control the CDF-1 duplicate and deliver a content copy to the CDF-2. CCF-1 also 
sends the new content storage information to the ALF which updates the location and other parameters 
appropriately. 
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For pull mode; CCF-2 will control the CDF-2 to acquire the duplicate copy from CDF-1 which will generate 
the duplicate copy. CCF-2 also sends the new content storage information to the ALF which updates the 
location and other parameters appropriately. 

10) CCF-2 updates the ALF database with the new content information in the cluster. 

11) CCF-2 notifies the CDNCF that the content is available in the cluster. 
NOTE: Steps 4 through 1 1 may be conducted repeatedly. 

7.9.3 Duplication between two clusters under different CDNCFs 
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Figure 7.9.3.1 : Duplication of content copy between two clusters under different CDNCFs 

1) An (optional) external or internal trigger is sent to CDNCF for initiating the duplication of content copy. 

2) CDNCF-l sends the CDNCF Query request to ALF seeking the CDNCFs that may respond a content request. 

3) Based on the knowledge of the location information of CDNCFs, clusters and the content location information 
in each cluster, ALF searches its database whether the request content can be matched. If matched record(s) 
have been found, ALF selects at least one appropriate CDNCF (as specified in clause 5.2.4) that controls a 
cluster appropriate for the UE's address for the content request, as the target CDNCF and returns the 
information (e.g. identifier) of the target CDNCF(s) to the source CDNCF (CDNCF-l); if no match is found, 
the ALF returns failure information to CDNCF-l and this procedure is stopped. 

4) CDNCF-l selects an appropriate CDNCF (CDNCF-2) that controls a cluster able to duplicate and deliver a 
content copy to the cluster which is under the control of CDNCF-l, and sends the duplicate request to 
CDNCF-2. 

5) CDNCF-2 selects a CCF (CCF-2) and the selected CCF-2 selects a CDF (CDF-2) for the duplicate request. 
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6) CDNCF-2 returns the information of the selected CDF-2 to CDNCF- 1 . 

7) CDNCF- 1 selects an appropriate CCF(CCF-l), and the selected CCF-1 selects an appropriate CDF(CDF-l) 
that may receive the duplicate content copy. 

8) Content Delivery: 

For Push mode; CCF-2 will control CDF-2 to duplicate and deliver a content copy to the CDF-1. CCF-1 will 
also send the new content storage information to the ALF which will update its storage information 
respectively. 

For Pull mode; CCF-1 will control CDF-1 to acquire the duplicate copy from CDF-2 which will generate the 
duplicate copy. CCF-1 also sends the new content storage information to the ALF which updates the location 
and other parameters appropriately. 

9) CCF-1 updates the ALF database with the new content information in the cluster. 

10) CCF-1 notifies the CDNCF that the content is available in the cluster. 
NOTE: Steps 4 through 1 1 may be conducted repeatedly. 

7.9.4 Media Relay based unicast streaming delivery for IMS based IPTV 



7.9.4.1 



Content deployment & delivery flow by media relay between two clusters 



Figure 7.9.4.1.1 provides an overview of the information flows for media relay based unicast streaming delivery flow 
among clusters. 



UE 



Core IMS/ 
SCF/RACS 



CDNCF 



ID Session RequestD Resource 
ReserveD 



2D 



session request 



Cluster 1 



Cluster 2 



CCF 



30 Allocation 
Cluster 



4D Content request 



CDF 



CCF 



CDF 



5D Cluster 1 get the content from Cluster 2 



6D Content Delivery 
Session Setup 



7D Response 



session response 



9D Session Response 
D Resource ReserveD 



Figure 7.9.4.1.1 : Content delivery flow by media relay among clusters 
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1) The sequence is triggered by an action from the user. The user requests unicast content which result is a 
unicast session request from UE to the Core IMS. 

2) The core IMS forward the service session request to the CDNCF. 

3) The CDNCF selects cluster 1 to serve the UE, according to the delivery policy. 

4) The CDNCF sends the session request to the selected CCF of Cluster 1. 

5) Optionally, if cluster 1 has the serving capability but the requested content is not in Cluster 1, the CDNCF 
indicates to cluster 1 to acquire the media from Cluster 2. The Cluster 1 gets the content from Cluster 2 as 
specified in clause 7.9.2. 

NOTE 1 : The CDF within Cluster 1 can read the content remotely from the CDF within Cluster 2 or download the 
content when it is popular according to the content deployment policy. 

NOTE 2: Resource reservation may be required between cluster 1 and cluster 2 to assure delivery of content to 
Cluster 1. 

6) The CCF of cluster 1 sends the session request to the appropriate CDF of cluster 1 and setup the content 
delivery session. 

7) The CCF of cluster 1 sends the acknowledge message to the CDNCF. 

8) The CDNCF sends the service session setup response to the Core IMS. 

9) The Core IMS forwards the service session response to the UE. Reserved resource is committed in this step. 

NOTE 3: After this step, stream control requests generated by the UE are targeted to the CDF of cluster 1 directly 
or via CCF of cluster 1, then UE receives stream from CDF of cluster 1. 

NOTE 4: Step 1 refers to steps 1 to 4 in clause 8.4.1.1.1 inTS 182 027 [2] and step 9 refer to steps 7 to 11 in 
clause 8 .4. 1 . 1 . 1 in TS 1 82 027 [2] . 

NOTE 5: Resource reservation in step 9 refers to the streaming resources from the CDF within cluster 1 to the UE. 

7.9.4.2 Content delivery flow by media relay via centre cache 

This clause gives two service flows for media relay based unicast streaming deliver flow via centre cache for PUSH or 
PULL respectively as depicted in figures 7.9.4.2.1 and 7.9.4.2.2. 

The centre cache can be a cloud network, a super server or a cluster. If the centre cache is constituted by a cluster, it will 
contain the CCF and CDF, while for the content delivery flow, the interactions between the CCF and CDF within the 
centre cache will not be defined in the present document. 
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Figure 7.9.4.2.1 : Content delivery flow PUSH by media relay via centre cache 

1) The SCF initiates the content PUSH. 

2) The media content is PUSHed to cluster 1 by the centre cache. 

3) At suitable occasion, the content in cluster 1 is activated for the content service. Before the activation, the 
content will not be able for content service. 

4) The content is delivered to UE as described in steps 1 to 4 and 7 to 9 in figure 7.9.4.1.1. 
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Figure 7.9.4.2.2: Content delivery flow PULL by media relay via centre cache 

1) The UE initiates the content PULL. 

2) The request is forwarded to cluster I. The media content is then PULLed by cluster 1 from the centre cache. 

3) At suitable occasion, the content in cluster 1 is activated for the content service. Before the activation, the 
content will not be able for content service. 

4) The content is delivered to UE as described in steps 7 to 9 in figure 7.9.4.1.1. 

7.1 Procedures of content removal 

The following clauses describe the procedures of content removal for CDN. 

7.10.1 Procedures for content removal CCF initiated 

A CCF may be triggered and may choose to remove a content item, or some copies of this content from its cluster. 
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Figure 7.10.1.1: Content removal CCF initiated 

1) CCF can be internally or externally triggered to remove copy(ies) of content. 

2) When it is the last copy of the cluster, unless it is a mandatory removal request, the CCF should request the 
ALF the authorization to delete content from its cluster. 

3) If step 2 occurs, the ALF should answers the CCF the authorization to delete the content. 

4) CCF sends a content removal request to the CDF. 

5) CDF deletes the content. 

6) CDF answers the CCF that the content has been deleted. 

7) CCF notifies the ALF that the content (or a copy of the content) is deleted from its cluster. 

8) CCF notifies the CDNCF that the content (or a copy of the content) is deleted from its cluster. 
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7.10.2 Procedures for content removal CDNCF initiated 
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Figure 7.10.2.1 : Content removal CDNCF initiated 

1) An (optional) external or internal trigger is sent to CDNCF for initiating the deletion of content copy. 

2) The CDNCF (optionally) sends the metrics request to the CCF acquiring the statistics of the content usage in a 
time range. 

3) If step 2 occurs, the CCF returns the CDNCF the record of usage information of that specific content that may 
contain the UE's identifier, content copy identifier(s), content issuer and the number of content requests in the 
specific period. 

4) If the CDNCF judges that the content is not frequently used in that specific period and the total number of 
requests is less than a down threshold, CDNCF requests the CCF to delete the desired content copy(s). 

5) CCF initiated deletion as shown in procedure 7. 10. 1 . 

6) The CCF responds to the CDNCF of the content copy's deletion. 
NOTE: Steps 4 through 8 may be conducted repeatedly. 

7.1 0.3 Procedures for mandatory content removal COF initiated 

This clause describes the procedures of content removal for CDN. A content item may need to be removed from the 
CDN in case of right violation for example (e.g. content reproducing a part of a movie without the allowance of the 
content owner). 



£75/ 



69 



ETSI TS 182 019 V3.1.2 (2011-09) 



COF 



(1) ExternalTrigger 



CDNCF 



(2) Content 
Deletion 



CCF 



CDF 



ALF 



(3) Content Remo' 



/a\ Notification 



(5) Con 



ent Removal Reques 



(4) 

CDNCF(s) 

selection 



(6) CDNCF initiated content removal (7.9.2) 



(8) Content 



(7) Content Removal Response 



Removal response 



Figure 7.10.3.1 : COF initiated lUlandatory Content removal 

1) Optionally, the COF may be instructed to remove all the copies of a content item from the CDN. 

2) If present on the COF, the COF should delete content. 

3) COF issues a content removal notification to notify the ALF to delete all the copies of a content item. 

4) ALF selects CDNCF(s) that are known to manage CCF(s) having the content. 

5) ALF sends a content removal request to the selected CDNCF(s). 

6) CDCNF initiated content removal (as shown in clause 7. 10.2). 

NOTE: Steps 5 and 6 should be repeated for each CDNCF containing the content. 

7) CDNCF sends a content removal response to the ALF. 

8) ALF sends a content removal response to the COF. 

7. 1 0.4 Procedures for COF content removal 

This clause describes the procedures of content removal for COF. Content may need to be removed from the COF in 
case of space management. 
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Figure 7.10.4.1 : COF Content removal 

1) Optionally, the COF may be instructed to remove content. 

NOTE: In the case where the COF is not serving as a centre cache, the COF may also initiate removal of all the 
copies of a content item from the CDN as shown in clause 7.9.3. 

2) The COF deletes content. 

3) COF issues a content removal notification to notify the ALF that the content is not available on the COF 
anymore. 

4) ALF sends a content removal response to the COF. 

7.1 0.5 Procedures for content removal on CDF (optional procedure) 

The call flow depicts the case when a CDF deletes content from its cache. 
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Figure 7.10.5.1 : CDF content removal 

The following is a description of the steps in the call flow for CDF content removal: 

1) Based on internal triggers in the CDF, the CDF decides to delete content from its cache. 

2) CDF issues a message to the CCF requesting the deletion of content. 
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3) CCF answers to the CDF that its request has been received. 

4) CCF initiated content removal (as described in clause 7.10. 1). 
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Annex A (informative): 
CDN steps description 



This annex describes the CDN steps depicted in clause 4.2. Figure A. 1 highlights four steps related to content 
distribution processes and delimits the scope of standardization work: 

1) The first step is content acquisition. This is how the CDN provider gets the content in the first place from the 
content source. The content source can be a content provider or a user (in case of UGC). The obtained content 
is not immediately deliverable it has to go through a preparation phase which is part of the ingestion step. 

2) The second step is content ingestion. It contains two main activities: content preparation and deployment 
Policy management: 

Content preparation includes content checking, coding adjustment, protection, adaptation, metadata 
association. 

Deployment policy management dictates the rules for content deployment (e.g. popular content - wide- 
spread deployment; regional content - deployed depending on geographical location; seldom-used 
content - deployed on central servers). 

Ingestion results in placing "ready for delivery" content in an initial storage location. 

3) The third step is deployment. This is where the content is duplicated to several copies or chunks and spread to 
multiple storage locations in the CDN. The deployment respects the deployment rules elaborated in the 
ingestion step. 

Deployment results in indicating to the service layer that the content is ready for delivery. At this point 
users will be able to request it. 

4) The fourth step is delivery. This is where the content is delivered from the most appropriate location to the 
users. Delivery is always initiated by the user or the service (including advertising use cases). 
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Figure A.1 : CDN steps description 
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Annex B (normative): 

CDN mapping to IPTV subsystems 

B.1 CDN mapping to llVIS-based IPTV subsystem 
(TS 182 027 [2]) 

For the IMS-based IPTV subsystem, the Content Delivery Network (CDN) may take the place of the IPTV media 
function described in TS 182 027 [2], clause 5.1.5.3. 




Figure B.1.1 : CDN mapping to llVIS-based IPTV subsystem 

The CDNCF and the CCF take the place of the MCF. The CDF in charge of content delivery takes the place of the 
MDF. The ALF and COF do not replace specific IMS IPTV functional entities. 



B.2 CDN mapping to NGN integrated IPTV subsystem 
(TS 1 82 028 [3]) 

For the NGN integrated IPTV subsystem, the Content Delivery Network (CDN) may take the place of the IPTV Media 
Function (MF, including MCF and MDF) described in TS 182 028 [3], clause 5.1.1. 

The NGN Integrated IPTV should be interconnected with Content Delivery Networks (CDN) as follows: 

• IPTV Control (IPTV-C) interconnected with CDN via reference point Cu, Qt (CDNCF) or Ct (CCF) to 
initiate/request and control media delivery. 
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UE interconnected with CDN via reference point Xc' (to CCF) and Xc"/Xd' (to CDF) using same protocols as 
over Xc (to MCF) and Xd (to MDF) reference point. 
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Figure B.2.1 : CDN mapping to NGN integrated IPTV subsystem 

The CDNCF and the CCF take the place of the MCF. The CDF in charge of content delivery takes the place of the 
MDF. The ALF and COF do not replace any specific core IPTV functional entities. 

NOTE: There can be an inter-relationship with or overlapping of functionalities between the ALF and COF, with 
NGN integrated IPTV supporting functions like Media Acquisition Function, Media Preparation FE 
and/or Media Distribution FE (see figure 2: NGN IPTV functional architecture in [3] and clause 5.1.2). 
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Annex C (informative): 
Architectural topologies 



CDNs may be deployed in several architectural topologies, including Single-Instance, Flat, and Hierarchical, as 
described in the clauses which follow. Hybrid topologies mixing these styles are also possible. 



C.1 Single-instance CDN architecture 

A Single-instance topology of a CDN acts as an evolvable implementation of the Media Function (MF), with a single 
CDNCF-managing one or more clusters providing the Media Control Function (MCF) and Media Delivery Function 
(MDF) described within the IMS-based IPTV subsystem (TS 182 027 [2]) and/or the NGN Integrated IPTV subsystem 
(TS 182 028 [3]). 



CDN 



Cluster 




Figure C.1.1 : Single-instance CDN topology 



C.2 Flat CDN architectural topology 

A flat CDN topology consists of multiple CDNCFs, all connected to at least one ALF, each CDNCF managing one or 
more clusters, interacting when necessary by exchanging control information. At least one ALF is mandatory for a 
CDN. 
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CDN 




NOTE: Connections between CDNCFs at the same level may take different forms based on implementation, 
including, chain, star, and ring topologies. 

Figure C.2.1 : Flat CDN topology 

The flat CDN acts as a scalable implementation of the Media Function (MF), including the Media Control Function 
(MCF) and Media Delivery Function (MDF) as described within the IMS-based IPTV subsystem (TS 182 027 [2]) 
and/or the NGN Integrated IPTV subsystem (TS 182 028 [3]). 



C.3 Hierarchical CDN architectural topology 

A Hierarchical CDN topology consists of a series of CDNCF-managed clusters, interacting when necessary by 
exchanging control information with one or more higher-tier CDN Controllers. At least one ALF is mandatory for a 
CDN. The functions of higher-tier CDNCFs may be specialized, and there may be a single highest-tier CDN Controller 
designated as a Top-tier CDNCF. A hierarchical CDN acts as a scalable implementation of the Media Function (MF), 
including the Media Control Function (MCF) and Media Delivery Function (MDF) as described within the IMS-based 
IPTV subsystem (TS 182 027 [2]) and/or the NGN Integrated IPTV subsystem (TS 182 028 [3]). 




Cluster(s) 



NOTE 1 : CDNCFs at any level may take different forms based on implementation, including CDNCFs without an 

ALF or directly associated clusters. 
NOTE 2: Connections between CDNCFs at the same level may take different forms based on implementation, 

including, chain, star, and ring topologies. 

Figure C.3.1: Hierarchical CDN topology 
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Annex D (informative): 
Interconnection scenarios 

D.1 Interconnection between TISPAN CDNs in different 
service provider domains with agreement on content 
preparation 

Different service providers may choose to interconnect their CDN in order to share content for example. Figures below 
show examples of interconnection for CDNs belonging to two different service provider domains. 

D.1 .1 Interconnection between TISPAN CDNs in different service 
provider domains without using content originating function 



Domain 2 




Figure D.1. 1.1: Example interconnection between TISPAN CDNs in different service provider domains 

without using content originating function 
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D.1 .2 Interconnection between TISPAN CDNs in different service 
provider domains using content originating function 
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Figure D. 1.2.1: Example interconnection between TISPAN CDNs 
in different service provider domains using content originating function 

D.1 .3 Interconnection between TISPAN CDNs in different service 
provider domains using ALF 
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Figure D.1. 3.1: Example interconnection between TISPAN CDNs 
in different service provider domains using ALF 
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D.2 Interconnection between TISPAN CDNs in different 
service provider domains without agreement on 
content preparation 

D.2.1 Interconnection between TISPAN CDNs in different service 
provider domains using Cf 




Figure D.2. 1.1: Example interconnection between TISPAN CDNs 
in different service provider domains using Cf 
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D.2.2 Interconnection between TISPAN CDNs in different service 
provider domains using Cf" 
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Figure D.2.2. 1 : Example interconnection between TISPAN CDNs 
in different service provider domains using Cf" 
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